Re: [Discuss-gnuradio] Working with GRC! Vector decimate

[Marcus D. Leech]

On 03/16/2018 10:57 AM, Glen I Langston wrote:

Hi

Thanks for your help.  I know no-one else cares, but
I’ve finally figured out all the steps to get Vector decimation working with 
GRC.

A few notes:  I don’t think forecast() is ever called with a decimate block.

Multiple output vectors are possible, and care needs to be taken to count
all the outputs.

My initial QA only had one vector output, so worked fine.
GRC was generating multiple vectors as output and my vave code was chocking
on multiple outputs.

I’ve yet to figure out how to put this block in GitHub


Glen:

First, congrats on getting your first custom block working.  I pop the 
virtual champagne cork in your general direction.


Next, rough outline of getting your stuff on GitHub:

Create a GitHub account.  Create a project.

Do an initial git clone of the project, and move your "stuff" into there.

Git "add" all the pieces that should be under source control.

Git "commit -a"

Git push

There, you have an initial instance of your stuff.

Now, since this block just does the (rough) equivalent (at the moment) 
of a single-pole-IIR filter followed by a keep-one-in-N, it would be 
useful to compare
  performance of your fused block.  I suspect that it will be 
poorer--because it's written in Python.


A fairer test would be to create a fused averager+decimator in C++, 
taking advantage of whatever SIMD tricks might be available.  The savings
  on "fused" blocks are that they localize data-motion, but they may, 
for significant-sized inputs, lose out due to the single-threaded nature 
of them.


Optimization is tricky, and it's not always obvious that any given 
approach will "always work".






___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-modtool overhaul: Proposal draft

[swapnil negi]

Hi Nicoloas!
Thanks for your valuable response.
Regarding Python compatibility - I will work upon version independent
compatibility using information from the following links:
Link[1]  Link[2]

Regarding specific milestones - I have now listed the work that can be
assessed after the completion of various phases.
Regarding CV: I have removed the section of such personal details from the
CV as well as proposal.

Cheers,
Swapnil Negi

On Fri, Mar 16, 2018 at 5:45 PM, Nicolas Cuervo 
wrote:

> Hello Swapnil Negi,
>
> Thank you for your proposal! This project has been in the pipeline for
> long and I'm very excited to see your interest in working on it. I have
> very few comments for now, but the discussion can definitely continue open:
>
> So the timeline that you are proposing is:
> 1) Python3 Compatible
> 2) Implement Plugin Architecture
> 3) Restructure code in favor of functional behavior
> 4) work on UI if time allows
>
> And I agree with this timeline, as it puts core focus on the architectural
> overhaul without disregarding other details aside.
>
>- If I understand correctly, your first task to tackle is the Py3k
>compatibility, which is great. This is definitely something that needs to
>be done, as there is a continuous effort on making the whole GNURadio
>Python3 compatible. But Python2 is not EOL for little less than 2 years
>more, so continuous compatibility is something that has to be kept in mind.
>Let's take your proposed code for raiseException, whose implementation
>won't work on Python2. There are ways to ensure compatibility (using
>wrappers from 'six' for example, which adds a dependency - which can be
>discussed)
>I, however, see that the Python3 branch from GNU Radio already
>implements the syntax that you are proposing, so I might being just too
>picky on this. I expect comments on the matter from the list.
>
>- I see that you have put efforts in contributing already to the
>project by fixing some issues on the tool, and there is hardly a better way
>to get used to it and contribute to the project. No comment here apart from
>saying that we do appreciate you took that path as it puts you into context
>and improves the project. Win-Win!
>
>- I would work on the format of the proposal as well to help you make
>a better impression and increases your chances of this being accepted. In
>your timeline, be sure to explicitly say what deliverable can be expected
>when. It's good to know when you are going to start working on something,
>but it is also important to know when you are expected to have it finished.
>Words like "Milestone" or even "Deliverable" might make this clear, maybe
>around the evaluation dates.
>
>- I see that you included your CV, which is nice to have, but do you
>_really_ want your personal data (like phone and address) out in the open?
>
>
> I might come back with more comments, but for now this is looking
> promising!
>
> Cheers,
> - Nicolas
>
>
> On Fri, Mar 16, 2018 at 3:57 AM, swapnil negi 
> wrote:
>
>> Hello everyone, I am Swapnil Negi, an undergraduate from Indian Institute
>> of Technology Roorkee, India. I wish to contribute to the project idea
>> "gr-modtool overhaul". Here
>> 
>> is the draft of my proposal. Kindly review it and give your valuable
>> suggestins.
>> This is something that I expected from the discussion. If there's
>> something that I am missing out, please do inform me.
>> Thanks!
>>
>> Regards, Swapnil Negi
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problems with dvbt 8k 64QAM

[Ron Economos]

It depends on how impaired your captured signal is. Here's a list.

1) Signal to noise ratio. For 64QAM, you'll need about 20 dB of S/N, 
preferably more.


2) DC offset. If you have a large DC offset (big spike in the middle of 
the received spectrum), that can cause problems. Unlike LTE, DVB-T uses 
the center carrier, and a large DC offset will destroy that carrier.


3) Multipath. You can determine how much multipath you have from the 
flatness of the signal. Here's what my test setup looks like. There's a 
little multipath since the signal slopes up to the right. If you have 
large peaks and valleys, then you have significant multipath.


DVB-T RX

Ron

On 03/16/2018 04:26 AM, Juan Antonio wrote:

Thanks Ron

 Now The constellation at the exit of demod reference signal now locks .

The duration of the file is 4 minutes fifty seconds 290 seconds. The 
four cores work almost 100%


 At the moment I have not got a TS file at the exit that have content

  A question could now be:Why  a file created with gqrx from a real 
signal does not lock?


The only difference  I  see at a glance between a file created by gqrx 
and the one you send me is that yours has a much greater relation C/N 
that mine.


Best  regards



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Website security breach (gnuradio.org)

[Andrej Rode]

Hello,

Last week we discovered that the Wordpress installation of the website had been 
compromised. The compromise allowed access to the system to an unauthenticated, 
unprivileged
remote user for at least the past year.

In the worst case scenario it is possible that the website has been serving 
hostile scripts, but we can find no evidence of this having occured.
Due to the large security implications to the system running the website we 
have shut it down and are now serving a static snapshot of the website until 
further notice.
This compromise only affected the Wordpress website (gnuradio.org) and its 
MySQL database. The wiki, cgit repository, LiveDVD images, and everything else 
are not affected.

We are considering how best to improve the security of the website in the long 
run.

Cheers
Andrej

-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


signature.asc
Description: Digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM TX/RX

[guillaume.tochou]

Hello all,

I want to make a flow graph for transmitting and receiving OFDM 
modulated data. To be precise, I want to do a LTE-M "like" 
transmission/reception, so I am trying to transmit data with a BW of 
1.08 MHz OFDM.
To do so, I use the following configuration : samp_rate = 1.92 MHz, fft 
length = 128, number of sub carriers = 72 , cp = 32


I modified the tx_ofdm.grc example file 
(/gnuradio/gr-digital/examples/ofdm/tx_ofdm.grc)
To summary, I change the occupied carriers : range(-36, -21) + 
range(-20, -7) + range(-6, 0) + range(1, 7) + range(8, 21) + range(22, 
37),) ; pilot carriers and symbols unchanged ; double the sync words to 
be equal to fft length.


The problem is at the output of the "Tag debug" I have just those 
messages :

INFO: Parser returned #f
INFO: Detected an invalid packet at item 1496
..
INFO: Parser returned #f
INFO: Detected an invalid packet at item 681901

And the spectrum isn't "stable" at 1.08 MHz BW.

What am I doing wrong ? How the sync words are determine ? Should I add 
pilot/symbol carriers ?



Best Regards and thanks by advance,

Guillaume Tochou





_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.



tx_ofdm.grc
Description: application/gnuradio-grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Working with GRC! Vector decimate

[CEL]

Hi Glen,

that is *awesome*! 

Best regards,
Marcus

On Fri, 2018-03-16 at 10:57 -0400, Glen I Langston wrote:
> Hi
> 
> Thanks for your help.  I know no-one else cares, but
> I’ve finally figured out all the steps to get Vector decimation working with 
> GRC.
> 
> A few notes:  I don’t think forecast() is ever called with a decimate block.
> 
> Multiple output vectors are possible, and care needs to be taken to count
> all the outputs. 
> 
> My initial QA only had one vector output, so worked fine.
> GRC was generating multiple vectors as output and my vave code was chocking
> on multiple outputs.
> 
> I’ve yet to figure out how to put this block in GitHub
> .  Here
> are the bits and pieces.
> 
> Best regard
> 
> Glen
> 
> 
> > On Mar 15, 2018, at 4:32 PM, Müller, Marcus (CEL)  wrote:
> > 
> > Hi Glen, 
> > 
> > you can't be a complete failure. Else you wouldn't be part of this
> > community :) and you very certainly wouldn't be writing GNU Radio
> > blocks after only four weeks!
> > 
> > Quick look at your work:
> > 
> >out = output_items[0]
> ># get the number of input vectors
> >n = len( input_items)
> >print 'Number of work input vectors: ',n
> > 
> > hey, what's good for output_items is good for input_items, too!
> > Point I'm trying to make: "output_items" is in the end a container of
> > all output streams; remember, blocks can have multiple output streams.
> > You have exactly one, so you take that by saying 
> > out = output_items[0]
> > 
> > Same goes for input_items; you want the first one, so use
> > input_items[0] instead of input_items.
> > 
> > Hope that helps a bit!
> > 
> > Best regards,
> > Marcus
> > 
> > On Thu, 2018-03-15 at 16:23 -0400, Glen I Langston wrote:
> > > Hello GnuRadio fans,
> > > 
> > > I’m afraid I’m a complete failure at creating my own vector average
> > > with decimate block.  This is my 4th week at this endeavor...
> > > 
> > > I’ve run through a number of c++ and python web examples and each time am 
> > > getting
> > > hung up somewhere.
> > > 
> > > I’ve been following the examples from many gnu radio 
> > > web sites and trying to get them to complete
> > > 
> > > Including:
> > > https://wiki.gnuradio.org/index.php/OutOfTreeModules
> > > 
> > > I got the C++ example to work but could not get the python qa test to 
> > > pass.
> > > 
> > > In any case, the vector average with decimate must be an easy example
> > > but I can not get the qa part to work.
> > > 
> > > Is there anyone out there who could create the very rudimentary
> > > vector average with decimate that they could share?
> > > 
> > > Please find my code attached.  The python part is simple. 
> > > The QA part is not running yet.
> > > 
> > > I’ve started with:
> > > 
> > > gr_modtool create vave
> > > cd gr-vave
> > > gr_modtool add -t decimator -l python vave  
> > > 
> > > 
> > > 
> > > ___
> > > 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

[Discuss-gnuradio] Working with GRC! Vector decimate

[Glen I Langston]

Hi

Thanks for your help.  I know no-one else cares, but
I’ve finally figured out all the steps to get Vector decimation working with 
GRC.

A few notes:  I don’t think forecast() is ever called with a decimate block.

Multiple output vectors are possible, and care needs to be taken to count
all the outputs. 

My initial QA only had one vector output, so worked fine.
GRC was generating multiple vectors as output and my vave code was chocking
on multiple outputs.

I’ve yet to figure out how to put this block in GitHub#!/usr/bin/env python
# -*- coding: utf-8 -*-
# 
# Copyright 2018 <+YOU OR YOUR COMPANY+>.
# 
# This is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
# 
# This software is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this software; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
# 

import numpy
import copy
from gnuradio import gr

class vave(gr.decim_block):
"""
Vector Average with Decimation.   Only one vector is returned for N input.
This block is intended to reduce the downstream CPU load.
"""
def __init__(self, vlen, vdecimate):
gr.decim_block.__init__(self,
name="vave",
in_sig=[(numpy.float32, int(vlen))],
out_sig=[(numpy.float32, int(vlen))], 
decim=int(vdecimate))
self.vlen = int(vlen)
self.vdecimate = int(vdecimate)
self.sum = numpy.zeros(self.vlen)
self.count = 0
self.oneovern = 1./float(self.vdecimate)

def forecast( self, noutput_items, ninput_items):
if noutput_items == None:
return self.vdecimate
#print 'Forecast: ', noutput_items
for i in range(len(nout_items)):
ninput_items[i] = noutput_items[i]*self.vdecimate
#print 'Forecast: ', ninput_items
return ninput_items
#return self.vdecimate

def work(self, input_items, output_items):
"""
Work averages all input vectors and outputs one vector for all inputs
"""
inn = input_items[0]

# get the number of input vectors
n = len( input_items)  # number of input PORTS (only 1)
nv = len(inn)  # number of vectors in this port

nout = len( output_items) #number of putput ports
ini = inn[0]   # first input vector
li = len(ini)  # length of first input vector
#print 'Number work vectors: ', nv, ' Length: ',li
ncp = min( li, self.vlen)

noutports = len( output_items)
if noutports != 1:
print '!!! Unexpected number of output ports: ', noutports
out = output_items[0]  # vectors in PORT 0 
nout = len(out)# number of output vectors
out0 = out[0]  # get the first output vector
lo = len(out0) # length of 1st output vector
#print 'Number work outputs: ', nout,' Length: ',lo

iout = 0 # count the number of output vectors
for i in range(nv):
# get the lenght of one input
ini = inn[i]
ncp = min( li, self.vlen)

# now save this vector until all are received
self.sum[0:ncp] = self.sum[0:ncp] + ini[0:ncp]
self.count = self.count + 1

# indicate consumption of a vector from input

if self.count >= self.vdecimate:
# normalize output average
self.sum = self.oneovern * self.sum
#out0[:] = copy.deepcopy(self.sum)
outi = out[iout]
outi = self.sum
out[iout] = outi
iout = iout+1
# now reset the count and restart the sum
self.count = 0
self.sum = numpy.zeros( self.vlen)
#self.produce(0,len(output_items[0]))
#self.consume_each(nv)
#return no
# end for all input vectors
# if here, then not enough vectors input to produce an output
#self.consume(0,nv)
output_items[0] = out
#print 'N outputs: ', len(output_items[0]), iout
return len(output_items[0])
# end vave()

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# 
# Copyright 2018 <+YOU OR YOUR COMPANY+>.
# 
# This is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
# 
# This 

Re: [Discuss-gnuradio] event handler exception

[ogün levent]

gr-inspector  https://github.com/gnuradio/gr-inspector

2018-03-16 16:04 GMT+03:00 Müller, Marcus (CEL) :

> Where are these blocks from?
> On Fri, 2018-03-16 at 16:03 +0300, ogün levent wrote:
> > Hi Marcus,
> >
> > Sorry for that. Flowgraph is in the attachments.
> >
> > Thanks
> >
> > 2018-03-16 15:45 GMT+03:00 Müller, Marcus (CEL) :
> > > Hi Ogün,
> > >
> > > we're usually happier about just copied & pasted /text/ instead of a
> > > /screenshot of text/, but this is OK.
> > >
> > > Sadly, without knowing what you're doing in your flowgraph, we can't
> > > even take a realistic guess what you're doing. So, you would need to
> > > share a screenshot of your flowgraph.
> > >
> > > Best regards,
> > > Marcus
> > > On Fri, 2018-03-16 at 15:25 +0300, ogün levent wrote:
> > > > Hi all,
> > > >
> > > > I was working on a flowgraph in grc 3.7.10 which was running without
> any problem. After having an issue about the limesuiteGUI, I had to upgrade
> to 3.7.11. With the same flowgraph and parameters I am getting event
> handler error. Appreciate for any help many thanks.
> > > >
> > > > Best.
> > > >
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] event handler exception

[CEL]

Where are these blocks from?
On Fri, 2018-03-16 at 16:03 +0300, ogün levent wrote:
> Hi Marcus,
> 
> Sorry for that. Flowgraph is in the attachments.
> 
> Thanks
> 
> 2018-03-16 15:45 GMT+03:00 Müller, Marcus (CEL) :
> > Hi Ogün,
> > 
> > we're usually happier about just copied & pasted /text/ instead of a
> > /screenshot of text/, but this is OK.
> > 
> > Sadly, without knowing what you're doing in your flowgraph, we can't
> > even take a realistic guess what you're doing. So, you would need to
> > share a screenshot of your flowgraph.
> > 
> > Best regards,
> > Marcus
> > On Fri, 2018-03-16 at 15:25 +0300, ogün levent wrote:
> > > Hi all,
> > >
> > > I was working on a flowgraph in grc 3.7.10 which was running without any 
> > > problem. After having an issue about the limesuiteGUI, I had to upgrade 
> > > to 3.7.11. With the same flowgraph and parameters I am getting event 
> > > handler error. Appreciate for any help many thanks.
> > >
> > > Best.
> > >
> > > ___
> > > 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

Re: [Discuss-gnuradio] event handler exception

[ogün levent]

Hi Marcus,

Sorry for that. Flowgraph is in the attachments.

Thanks

2018-03-16 15:45 GMT+03:00 Müller, Marcus (CEL) :

> Hi Ogün,
>
> we're usually happier about just copied & pasted /text/ instead of a
> /screenshot of text/, but this is OK.
>
> Sadly, without knowing what you're doing in your flowgraph, we can't
> even take a realistic guess what you're doing. So, you would need to
> share a screenshot of your flowgraph.
>
> Best regards,
> Marcus
> On Fri, 2018-03-16 at 15:25 +0300, ogün levent wrote:
> > Hi all,
> >
> > I was working on a flowgraph in grc 3.7.10 which was running without any
> problem. After having an issue about the limesuiteGUI, I had to upgrade to
> 3.7.11. With the same flowgraph and parameters I am getting event handler
> error. Appreciate for any help many thanks.
> >
> > Best.
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] event handler exception

[CEL]

Hi Ogün,

we're usually happier about just copied & pasted /text/ instead of a
/screenshot of text/, but this is OK.

Sadly, without knowing what you're doing in your flowgraph, we can't
even take a realistic guess what you're doing. So, you would need to
share a screenshot of your flowgraph.

Best regards,
Marcus
On Fri, 2018-03-16 at 15:25 +0300, ogün levent wrote:
> Hi all,
> 
> I was working on a flowgraph in grc 3.7.10 which was running without any 
> problem. After having an issue about the limesuiteGUI, I had to upgrade to 
> 3.7.11. With the same flowgraph and parameters I am getting event handler 
> error. Appreciate for any help many thanks.
> 
> Best.
> 
> ___
> 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

[Discuss-gnuradio] event handler exception

[ogün levent]

Hi all,

I was working on a flowgraph in grc 3.7.10 which was running without any
problem. After having an issue about the limesuiteGUI, I had to upgrade to
3.7.11. With the same flowgraph and parameters I am getting event handler
error. Appreciate for any help many thanks.

Best.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-modtool overhaul: Proposal draft

[Nicolas Cuervo]

Hello Swapnil Negi,

Thank you for your proposal! This project has been in the pipeline for long
and I'm very excited to see your interest in working on it. I have very few
comments for now, but the discussion can definitely continue open:

So the timeline that you are proposing is:
1) Python3 Compatible
2) Implement Plugin Architecture
3) Restructure code in favor of functional behavior
4) work on UI if time allows

And I agree with this timeline, as it puts core focus on the architectural
overhaul without disregarding other details aside.

   - If I understand correctly, your first task to tackle is the Py3k
   compatibility, which is great. This is definitely something that needs to
   be done, as there is a continuous effort on making the whole GNURadio
   Python3 compatible. But Python2 is not EOL for little less than 2 years
   more, so continuous compatibility is something that has to be kept in mind.
   Let's take your proposed code for raiseException, whose implementation
   won't work on Python2. There are ways to ensure compatibility (using
   wrappers from 'six' for example, which adds a dependency - which can be
   discussed)
   I, however, see that the Python3 branch from GNU Radio already
   implements the syntax that you are proposing, so I might being just too
   picky on this. I expect comments on the matter from the list.

   - I see that you have put efforts in contributing already to the project
   by fixing some issues on the tool, and there is hardly a better way to get
   used to it and contribute to the project. No comment here apart from saying
   that we do appreciate you took that path as it puts you into context and
   improves the project. Win-Win!

   - I would work on the format of the proposal as well to help you make a
   better impression and increases your chances of this being accepted. In
   your timeline, be sure to explicitly say what deliverable can be expected
   when. It's good to know when you are going to start working on something,
   but it is also important to know when you are expected to have it finished.
   Words like "Milestone" or even "Deliverable" might make this clear, maybe
   around the evaluation dates.

   - I see that you included your CV, which is nice to have, but do you
   _really_ want your personal data (like phone and address) out in the open?


I might come back with more comments, but for now this is looking promising!

Cheers,
- Nicolas


On Fri, Mar 16, 2018 at 3:57 AM, swapnil negi 
wrote:

> Hello everyone, I am Swapnil Negi, an undergraduate from Indian Institute
> of Technology Roorkee, India. I wish to contribute to the project idea
> "gr-modtool overhaul". Here
> 
> is the draft of my proposal. Kindly review it and give your valuable
> suggestins.
> This is something that I expected from the discussion. If there's
> something that I am missing out, please do inform me.
> Thanks!
>
> Regards, Swapnil Negi
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problems with dvbt 8k 64QAM

[Juan Antonio]

Thanks Ron

 Now The constellation at the exit of demod reference signal now locks .

The duration of the file is 4 minutes fifty seconds 290 seconds. The four
cores work almost 100%

 At the moment I have not got a TS file at the exit that have content

  A question could now be:Why  a file created with gqrx from a real signal
does not lock?

The only difference  I  see at a glance between a file created by gqrx and
the one you send me is that yours has a much greater relation C/N that mine.

Best  regards
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problems with dvbt 8k 64QAM

[Ron Economos]

You have to set the Cyclic Prefix Length on the OFDM Symbol Acquisition 
block to 2048 to match the 1/4 guard interval (8192/4 = 2048).


Ron

On 03/16/2018 03:06 AM, Juan Antonio wrote:
I have been running the file for 15 minutes and it is still working 
even though the file source repeater is set to no.


  The constellation at the exit of the FTT block engages with 64 
points (+5), randomly engages and at 2 seconds they appear in a 
circular way (this also made it to the adv16.cfile file), re-lock  
them and the 2 seconds later or less appear in a circular way and so 
consecutively


  The constellation to the output of demod reference signal only 
appears with a point in the center. The processor cores work at 50%


Best  regards




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problems with dvbt 8k 64QAM

[Juan Antonio]

I have been running the file for 15 minutes and it is still working even
though the file source repeater is set to no.

  The constellation at the exit of the FTT block engages with 64 points
(+5), randomly engages and at 2 seconds they appear in a circular way (this
also made it to the adv16.cfile file), re-lock  them and the 2 seconds
later or less appear in a circular way and so consecutively

  The constellation to the output of demod reference signal only appears
with a point in the center. The processor cores work at 50%

Best  regards
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio