Re: [Discuss-gnuradio] Setting the max output items in OOT Module

[Marcus Müller]

Hi Nigel,

this sounds like you should rather be limiting the input item number of
your next block.

So do I get this right: We're looking at three blocks here:

A-->B-->C

What you want to do is limit the number of output items the scheduler
asks for at block B, right? Block A is the one where you want to limit
the size of data input to, and C is the one that retunes?

GNU Radio really just politely asks for a number of output items. If you
have reason to produce less, you can simply produce less. Problem might
be that GNU Radio, based on the "busyness" of the block downstream
(these all run concurrently, so the moment that B produces one sample, C
might still be work()ing on the previous one(s) , and by the time it's
finished, there already might be more than one item accumulated in C's
input buffer).

Is it that the potential aggregation of samples in C's input buffer
leads to latency is problematic for your application?

Best Regards,
Marcus


On 01/27/2016 10:44 PM, Nigel Steed wrote:
>
> Hi,
>
>  
>
> Can anyone help me set the maximum output number of items within the C
> Code of a GNU Radio OOT block ? I am trying to set this to a single
> sample as its a decimating block and I need the next block to retune
> at specific sample times whilst controlling the scheduler to limit the
> size of data input to the previous block so I can control what
> frequency data has been acquired.
>
>  
>
> Thanks,
>
>  
>
> Nigel
>
>  
>
>
>
> ___
> 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] Question regarding correlating output and IQ samples in a reciever

[Marcus Müller]

Hi Abhinav,

On 01/28/2016 04:32 AM, abhinav narain wrote:
> Hi Marcus, 
>
> timing offset estimate) that your symbols have duration of
> 2.236472 samples and start with a sample offset of 114.060072; I
> don't see how knowing that would map the end of a preamble to any
> "exact" sample.
>
>  If I understand this, it is not straightforward to find the end of
> the preamble, to start the clock for the data transmission part. I can
> approximately chop the preamble off then.
Well, the preamble is, by definition, not part of your data, so you'd
wanna chop it off as soon as you've used it to synchronize/get channel
state info, anyway.
>
>
>
> I am simply doing OOK.
>  
>
> Generally, $\frac{S+N}{N}$ is only really a useful measure if you
> either have
>
>  1. a constant power modulation (e.g. PSK), or
>  2. whiten your over-the-air bits sufficiently (using /coding/),
> so that for (stochastically speaking almost any) data
> sequence, the signal power is the same.
>
> Usually, even when you have 1., you do 2..
>
> so the above formula is what I am using currently over the whole
> message run, and for similar amount of time when no message was
> transmitted to get S+N/N .
> I have looked through Gnuradio docs and doesn't seem to appeal that
> there is any of the four would work.
Sorry, I don't understand what you're referring to; could you explain?
> Their output varies significantly amongst one another and hard to say
> which one is correct (as mentioned in the docs, some implementations
> are to be used cautiously).
>
> If you measure SNR based on a subset of bits that actually have
> energy, you're biasing your measurement, and it won't have any
> meaning for your real transmission, unless you've done the math
> and know that these bits represent a certain percentage of the
> power of an actual transmission. But as soon as you do the math,
> and figure out that some bits have higher Energy per bit $E_b$,
> you'd try to minimize the average $E_b$, so that you can just
> increase the signal amplitude without breaking your
> specifications, and get a higher average SNR; this implies
> spreading the energy over different bits more evenly, and that
> just leads to the whitening mentioned above.
>
> Okay, then it makes sense to average the energy over the whole trace
> instead of searching for the isolated pulses and calculating SNR only
> due those samples.
>
Best regards,
Marcus
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] installing UHD using PyBOMBS 2.0

[Martin Braun]

Hey Rob,

thanks for trying PyBOMBS and sorry for the lack of an announcement on
usrp-users. I will announce it there once we release the next version
(which will be very soon) because I've fixed some issues and also made
UHD installation easier.

In your case, to install UHD, do the following:

1) Create a prefix. Run one of these commands:
  a) $ pybombs prefix init -a default ~/path/to/prefix
  b) $ sudo pybombs prefix init -a default /usr/local

The latter will put all source installs in the system, the former will
put them somewhere in your home dir. For the record: Most people will
want a).

2) Define this as the default prefix:
$ pybombs config default_prefix default

This step is not required, but if lets you skip the -p option for all
following PyBOMBS commands.

3) Now comes the complicated part, which will be changed in the next
version. PyBOMBS provides no defaults on which packages to install from
source rather than from apt-get or whatever. You need to configure your
prefix to override system defaults to source. To do this, edit the
/.pybombs/config.yml file and add the lines from here:
https://github.com/gnuradio/pybombs/blob/master/pybombs/skel/.pybombs/config.yml

(or just copy that file there).

4) Now you can just do 'pybombs install uhd' and it will install UHD
from source to your prefix. At any time, you can then 'pybombs  update
uhd' to re-pull master and re-build.

Hope this helps!

M

On 01/28/2016 12:11 AM, Rob Kossler wrote:
> Hi,
> I just setup a new system and as I attempted to install UHD via PyBOMBS,
> I stumbled on the PyBOMBS 2.0 changeover.  Since I typically only follow
> the usrp-users list and not the gnuradio list, I didn't see the
> announcement of this changeover.
> 
> I am having trouble with the install.  I really am only interested in
> installing UHD (source code install), so I tried the following line, but
> nothing really happened.  Afterwards, I do not see any UHD installation
> in my prefix location.  Also, it is not clear to me how I would choose
> whether this install should be a source install or binary install.
> 
> $ pybombs install uhd
> PyBombs.install - INFO - No packages to install.
> 
> Any idea why the above does not seem to do anything?
> 
> 
> When this didn't seem to work, I decided to go ahead and install
> gnuradio since previous PyBOMBS installs of this type would also install
> UHD as a source code install.  This install failed - the results are in
> the attached TXT file.  Basically, it looks like it can't find some
> boost component, but it is not clear to me why it couldn't fix the
> problem and install what it needed.  There are plenty of boost warnings,
> but I'm not sure if they are benign or not. 
> 
> Let me know any suggestions.  Thanks.
> 
> Rob
> 
> 
> ___
> 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

[Discuss-gnuradio] [FOSDEM] Reminder and Request for volunteers (AV)

[Martin Braun]

Hey everyone,

two more days 'til FOSDEM! I hope people are as excited as I am.
FOSDEM is this weekend in Brussels, and attendance is free.

Find our schedule here:
https://fosdem.org/2016/schedule/track/software_defined_radio/

Also, Tom Rondeau is giving a GNU Radio talk in a main track:
https://fosdem.org/2016/schedule/track/hardware/

One thing I would like to ask is if some of you could help with the AV.
At all times, we need one person to man the AV setup (apparently it's
super easy) and make the cuts so we get nice videos at the end. If
you'll be around anyway, that should be simple.

Also, and that's where I'm expecting less enthusiasm, but still need
help with, I need at least one person to help me set up the AV on Sunday
morning. And yes, that means getting up early on a *Sunday*. We need to
pick up the gear at sometime between 8 and 8:30.

Judging by talk submissions, we are one of the most popular tracks -- AV
volunteers get guaranteed access to the room! And for those who are new
to FOSDEM, we are legally obliged to close rooms once we reach max
capacity. We had long lines outside last time!

If you feel like you can help, please contact me. Thanks!

Martin

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

[Discuss-gnuradio] Doubt

[john cai]

Hello Guys

I am new to GNU Radio. I am sorry if the question is stupid.

Did anyone tried Successive Interference Cancellation using GNU Radio?

If so then is there any source code available related to that?

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

Re: [Discuss-gnuradio] Doubt

[Marcus Müller]

Hi John,
Welcome!

> Did anyone tried Successive Interference Cancellation using GNU Radio?
Probably someone has; however, it's not really very universally
applicable. A lot of how you would implement something like that depends
on the parameters of your waveforms. You'll have to  buffer at least
2*packetlength-1 samples of signal to make that work, so it's not really
a thing that maps very efficiently to GNU Radio's stream-based flow
graph idea. But sure, writing a block that does SIC should totally be
possible.

Best regards,
Marcus

On 01/28/2016 02:29 PM, john cai wrote:
> Hello Guys
>
> I am new to GNU Radio. I am sorry if the question is stupid. 
>
> Did anyone tried Successive Interference Cancellation using GNU Radio?
>
> If so then is there any source code available related to that?
>
> Awaiting for your reply 
>
>
> ___
> 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] installing UHD using PyBOMBS 2.0

[Rob Kossler]

Thanks for all the replies.

Following Martin's suggestion, I added the appropriate line to config.yml.
After this my install command attempted the source install, but died with
the same problem that my gnuradio install died yesterday -- problem finding
boost components.  I followed Derek's suggestion to install boost 1.54.
Unfortunately, that didn't fix the problem I'm having with the uhd
install.  (See attached txt file for details.)

Next, I edited the boost.lwr recipe and changed all "1.53" to "1.54" and
all "1_53" to "1_54".  Now, the uhd install works.  I'm not sure if this
was the right way to fix the problem but it worked for me.

However, I see that it installed the latest master
(UHD_003.010.git-0-42a3eeb6) even though I had modified the uhd recipe file
with the line "gitrev: tags/release_003_009_002" which is what has worked
for me in the past in order to get a specific version.  Perhaps the install
is not using the recipe file I think...

Martin, I do have one question about the lines you suggested that I add to
config.yml.  Without those lines, shouldn't the command "pybombs install
uhd" have done a binary install? Yesterday, I found no evidence of a binary
install, but today I found an old version 3.5.5. I'm not sure if this
installed during the uhd install or when I later tried to install
gnuradio.  In any event, I am wondering if there is a way to configure
pybombs to do a binary install but to use a specific version such as 3.9.2?

Rob


On Thu, Jan 28, 2016 at 5:18 AM, Martin Braun 
wrote:

> Hey Rob,
>
> thanks for trying PyBOMBS and sorry for the lack of an announcement on
> usrp-users. I will announce it there once we release the next version
> (which will be very soon) because I've fixed some issues and also made
> UHD installation easier.
>
> In your case, to install UHD, do the following:
>
> 1) Create a prefix. Run one of these commands:
>   a) $ pybombs prefix init -a default ~/path/to/prefix
>   b) $ sudo pybombs prefix init -a default /usr/local
>
> The latter will put all source installs in the system, the former will
> put them somewhere in your home dir. For the record: Most people will
> want a).
>
> 2) Define this as the default prefix:
> $ pybombs config default_prefix default
>
> This step is not required, but if lets you skip the -p option for all
> following PyBOMBS commands.
>
> 3) Now comes the complicated part, which will be changed in the next
> version. PyBOMBS provides no defaults on which packages to install from
> source rather than from apt-get or whatever. You need to configure your
> prefix to override system defaults to source. To do this, edit the
> /.pybombs/config.yml file and add the lines from here:
>
> https://github.com/gnuradio/pybombs/blob/master/pybombs/skel/.pybombs/config.yml
>
> (or just copy that file there).
>
> 4) Now you can just do 'pybombs install uhd' and it will install UHD
> from source to your prefix. At any time, you can then 'pybombs  update
> uhd' to re-pull master and re-build.
>
> Hope this helps!
>
> M
>
> On 01/28/2016 12:11 AM, Rob Kossler wrote:
> > Hi,
> > I just setup a new system and as I attempted to install UHD via PyBOMBS,
> > I stumbled on the PyBOMBS 2.0 changeover.  Since I typically only follow
> > the usrp-users list and not the gnuradio list, I didn't see the
> > announcement of this changeover.
> >
> > I am having trouble with the install.  I really am only interested in
> > installing UHD (source code install), so I tried the following line, but
> > nothing really happened.  Afterwards, I do not see any UHD installation
> > in my prefix location.  Also, it is not clear to me how I would choose
> > whether this install should be a source install or binary install.
> >
> > $ pybombs install uhd
> > PyBombs.install - INFO - No packages to install.
> >
> > Any idea why the above does not seem to do anything?
> >
> >
> > When this didn't seem to work, I decided to go ahead and install
> > gnuradio since previous PyBOMBS installs of this type would also install
> > UHD as a source code install.  This install failed - the results are in
> > the attached TXT file.  Basically, it looks like it can't find some
> > boost component, but it is not clear to me why it couldn't fix the
> > problem and install what it needed.  There are plenty of boost warnings,
> > but I'm not sure if they are benign or not.
> >
> > Let me know any suggestions.  Thanks.
> >
> > Rob
> >
> >
> > ___
> > 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
>
irisheyes1: ~$ 
irisheyes1: ~$ sudo apt-get install libboost1.53-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package libboost1.53-dev is not available, bu

Re: [Discuss-gnuradio] installing UHD using PyBOMBS 2.0

[Rob Kossler]

Martin,
One more thing...  Now, when I run the command "pybombs update uhd", I get
the reply "PyBombs.RecipeListManager - ERROR - Package None has no recipe
file!".

Rob

On Thu, Jan 28, 2016 at 9:37 AM, Rob Kossler  wrote:

> Thanks for all the replies.
>
> Following Martin's suggestion, I added the appropriate line to
> config.yml.  After this my install command attempted the source install,
> but died with the same problem that my gnuradio install died yesterday --
> problem finding boost components.  I followed Derek's suggestion to install
> boost 1.54.  Unfortunately, that didn't fix the problem I'm having with the
> uhd install.  (See attached txt file for details.)
>
> Next, I edited the boost.lwr recipe and changed all "1.53" to "1.54" and
> all "1_53" to "1_54".  Now, the uhd install works.  I'm not sure if this
> was the right way to fix the problem but it worked for me.
>
> However, I see that it installed the latest master
> (UHD_003.010.git-0-42a3eeb6) even though I had modified the uhd recipe file
> with the line "gitrev: tags/release_003_009_002" which is what has worked
> for me in the past in order to get a specific version.  Perhaps the install
> is not using the recipe file I think...
>
> Martin, I do have one question about the lines you suggested that I add to
> config.yml.  Without those lines, shouldn't the command "pybombs install
> uhd" have done a binary install? Yesterday, I found no evidence of a binary
> install, but today I found an old version 3.5.5. I'm not sure if this
> installed during the uhd install or when I later tried to install
> gnuradio.  In any event, I am wondering if there is a way to configure
> pybombs to do a binary install but to use a specific version such as 3.9.2?
>
> Rob
>
>
> On Thu, Jan 28, 2016 at 5:18 AM, Martin Braun 
> wrote:
>
>> Hey Rob,
>>
>> thanks for trying PyBOMBS and sorry for the lack of an announcement on
>> usrp-users. I will announce it there once we release the next version
>> (which will be very soon) because I've fixed some issues and also made
>> UHD installation easier.
>>
>> In your case, to install UHD, do the following:
>>
>> 1) Create a prefix. Run one of these commands:
>>   a) $ pybombs prefix init -a default ~/path/to/prefix
>>   b) $ sudo pybombs prefix init -a default /usr/local
>>
>> The latter will put all source installs in the system, the former will
>> put them somewhere in your home dir. For the record: Most people will
>> want a).
>>
>> 2) Define this as the default prefix:
>> $ pybombs config default_prefix default
>>
>> This step is not required, but if lets you skip the -p option for all
>> following PyBOMBS commands.
>>
>> 3) Now comes the complicated part, which will be changed in the next
>> version. PyBOMBS provides no defaults on which packages to install from
>> source rather than from apt-get or whatever. You need to configure your
>> prefix to override system defaults to source. To do this, edit the
>> /.pybombs/config.yml file and add the lines from here:
>>
>> https://github.com/gnuradio/pybombs/blob/master/pybombs/skel/.pybombs/config.yml
>>
>> (or just copy that file there).
>>
>> 4) Now you can just do 'pybombs install uhd' and it will install UHD
>> from source to your prefix. At any time, you can then 'pybombs  update
>> uhd' to re-pull master and re-build.
>>
>> Hope this helps!
>>
>> M
>>
>> On 01/28/2016 12:11 AM, Rob Kossler wrote:
>> > Hi,
>> > I just setup a new system and as I attempted to install UHD via PyBOMBS,
>> > I stumbled on the PyBOMBS 2.0 changeover.  Since I typically only follow
>> > the usrp-users list and not the gnuradio list, I didn't see the
>> > announcement of this changeover.
>> >
>> > I am having trouble with the install.  I really am only interested in
>> > installing UHD (source code install), so I tried the following line, but
>> > nothing really happened.  Afterwards, I do not see any UHD installation
>> > in my prefix location.  Also, it is not clear to me how I would choose
>> > whether this install should be a source install or binary install.
>> >
>> > $ pybombs install uhd
>> > PyBombs.install - INFO - No packages to install.
>> >
>> > Any idea why the above does not seem to do anything?
>> >
>> >
>> > When this didn't seem to work, I decided to go ahead and install
>> > gnuradio since previous PyBOMBS installs of this type would also install
>> > UHD as a source code install.  This install failed - the results are in
>> > the attached TXT file.  Basically, it looks like it can't find some
>> > boost component, but it is not clear to me why it couldn't fix the
>> > problem and install what it needed.  There are plenty of boost warnings,
>> > but I'm not sure if they are benign or not.
>> >
>> > Let me know any suggestions.  Thanks.
>> >
>> > Rob
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>>
>>
>> ___

[Discuss-gnuradio] Two usrp connected by mimo cable

[w xd]

Hi all,
 I want to use one pc to control two USRP to send and receive ofdm
signals synchronization in the grc.One USRP is used as transmitter and the
other one is used as receive.Can it be done by just connect two usrp by
mimo cable?

 Thanks in advance.

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

Re: [Discuss-gnuradio] installing UHD using PyBOMBS 2.0

[Ralph A. Schmid, dk5ras]

I really thought this has become easier now. After my attempts using pybombs 
and creating a whole mess in my system I decided to manually download and build 
all from source, uhd, gnuradio, and all the other stuff, good a dozen of 
gr-something packages. Then I made a simple script that git pulls and builds 
and installs everything in the correct order, to keep up to date.

The idea of pybombs is great, having almost the whole gnuradio world in one 
place, and maybe I will create a new VM just to try it out after its change to 
2.0 :)

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Rob 
Kossler
Sent: Thursday, January 28, 2016 3:37 PM
To: Martin Braun
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] installing UHD using PyBOMBS 2.0

 

Thanks for all the replies.

Following Martin's suggestion, I added the appropriate line to config.yml.  
After this my install command attempted the source install, but died with the 
same problem that my gnuradio install died yesterday -- problem finding boost 
components.  I followed Derek's suggestion to install boost 1.54.  
Unfortunately, that didn't fix the problem I'm having with the uhd install.  
(See attached txt file for details.)

Next, I edited the boost.lwr recipe and changed all "1.53" to "1.54" and all 
"1_53" to "1_54".  Now, the uhd install works.  I'm not sure if this was the 
right way to fix the problem but it worked for me.

However, I see that it installed the latest master (UHD_003.010.git-0-42a3eeb6) 
even though I had modified the uhd recipe file with the line "gitrev: 
tags/release_003_009_002" which is what has worked for me in the past in order 
to get a specific version.  Perhaps the install is not using the recipe file I 
think...

 

Martin, I do have one question about the lines you suggested that I add to 
config.yml.  Without those lines, shouldn't the command "pybombs install uhd" 
have done a binary install? Yesterday, I found no evidence of a binary install, 
but today I found an old version 3.5.5. I'm not sure if this installed during 
the uhd install or when I later tried to install gnuradio.  In any event, I am 
wondering if there is a way to configure pybombs to do a binary install but to 
use a specific version such as 3.9.2?

 

Rob

 

On Thu, Jan 28, 2016 at 5:18 AM, Martin Braun mailto:martin.br...@ettus.com> > wrote:

Hey Rob,

thanks for trying PyBOMBS and sorry for the lack of an announcement on
usrp-users. I will announce it there once we release the next version
(which will be very soon) because I've fixed some issues and also made
UHD installation easier.

In your case, to install UHD, do the following:

1) Create a prefix. Run one of these commands:
  a) $ pybombs prefix init -a default ~/path/to/prefix
  b) $ sudo pybombs prefix init -a default /usr/local

The latter will put all source installs in the system, the former will
put them somewhere in your home dir. For the record: Most people will
want a).

2) Define this as the default prefix:
$ pybombs config default_prefix default

This step is not required, but if lets you skip the -p option for all
following PyBOMBS commands.

3) Now comes the complicated part, which will be changed in the next
version. PyBOMBS provides no defaults on which packages to install from
source rather than from apt-get or whatever. You need to configure your
prefix to override system defaults to source. To do this, edit the
/.pybombs/config.yml file and add the lines from here:
https://github.com/gnuradio/pybombs/blob/master/pybombs/skel/.pybombs/config.yml

(or just copy that file there).

4) Now you can just do 'pybombs install uhd' and it will install UHD
from source to your prefix. At any time, you can then 'pybombs  update
uhd' to re-pull master and re-build.

Hope this helps!

M


On 01/28/2016 12:11 AM, Rob Kossler wrote:
> Hi,
> I just setup a new system and as I attempted to install UHD via PyBOMBS,
> I stumbled on the PyBOMBS 2.0 changeover.  Since I typically only follow
> the usrp-users list and not the gnuradio list, I didn't see the
> announcement of this changeover.
>
> I am having trouble with the install.  I really am only interested in
> installing UHD (source code install), so I tried the following line, but
> nothing really happened.  Afterwards, I do not see any UHD installation
> in my prefix location.  Also, it is not clear to me how I would choose
> whether this install should be a source install or binary install.
>
> $ pybombs install uhd
> PyBombs.install - INFO - No packages to install.
>
> Any idea why the above does not seem to do anything?
>
>
> When this didn't seem to work, I decided to go ahead and install
> gnuradio since previous PyBOMBS installs of this type would also install
> UHD as a source code install.  This install failed - the results are in
> the attached TXT file.  Basically, it looks like it can't find some
> boost component, but it

Re: [Discuss-gnuradio] Two usrp connected by mimo cable

[Marcus Müller]

Yes. The MIMO cable forwards the data as if it was a network cable and a
switch.

Best regards,
Marcus

On 01/28/2016 04:18 PM, w xd wrote:
> Hi all,
>  I want to use one pc to control two USRP to send and receive
> ofdm signals synchronization in the grc.One USRP is used as
> transmitter and the other one is used as receive.Can it be done by
> just connect two usrp by mimo cable?
>
>  Thanks in advance.
>
> Best regards,
> zs
>
>
> ___
> 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] Two usrp connected by mimo cable

[w xd]

Hi:
  Thanks so much.I want to realize the transmit and receive ofdm signal
in one pc.Also I want to realize the synchronization.Just combine the
tx_ofdm and rx_ofdm grc in one grc and just run?Any suggestion is
grateful.Thanks.


2016-01-28 23:44 GMT+08:00 Marcus Müller :

> Yes. The MIMO cable forwards the data as if it was a network cable and a
> switch.
>
> Best regards,
> Marcus
>
>
> On 01/28/2016 04:18 PM, w xd wrote:
>
> Hi all,
>  I want to use one pc to control two USRP to send and receive ofdm
> signals synchronization in the grc.One USRP is used as transmitter and the
> other one is used as receive.Can it be done by just connect two usrp by
> mimo cable?
>
>  Thanks in advance.
>
> Best regards,
> zs
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> 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] Two usrp connected by mimo cable

[Marcus Müller]

Yes you can do that. Also, most daughterboards you can use with the N2x0
are full-duplex capable, so you don't even need to use two USRPs.

On 01/28/2016 04:47 PM, w xd wrote:
> Hi:
>   Thanks so much.I want to realize the transmit and receive ofdm
> signal in one pc.Also I want to realize the synchronization.Just
> combine the tx_ofdm and rx_ofdm grc in one grc and just run?Any
> suggestion is grateful.Thanks.
>
>
> 2016-01-28 23:44 GMT+08:00 Marcus Müller  >:
>
> Yes. The MIMO cable forwards the data as if it was a network cable
> and a switch.
>
> Best regards,
> Marcus
>
>
> On 01/28/2016 04:18 PM, w xd wrote:
>> Hi all,
>>  I want to use one pc to control two USRP to send and
>> receive ofdm signals synchronization in the grc.One USRP is used
>> as transmitter and the other one is used as receive.Can it be
>> done by just connect two usrp by mimo cable?
>>
>>  Thanks in advance.
>>
>> Best regards,
>> zs
>>
>>
>> ___
>> 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
>
>

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

Re: [Discuss-gnuradio] Two usrp connected by mimo cable

[w xd]

Thanks so much.
1.Is sbx support the full-duplex?
2.If I use one pc and one usrp to realize the transmit and receive.Does the
frequency offset exist?
3.Have some related examples in grc which use one pc to control one usrp to
realize the transmit and receive?Have some related examples in grc which
use one pc to control two usrp connect by the mimo cable to realize the
transmit and receive?

Best regards

2016-01-29 0:01 GMT+08:00 w xd :

> Thanks so much.
> 1.Is sbx support the full-duplex?
> 2.If I use one pc and one usrp to realize the transmit and receive.Does
> the frequency offset exist?
> 3.Have some related examples in grc which use one pc to control one usrp
> to realize the transmit and receive?Have some related examples in grc which
> use one pc to control two usrp connect by the mimo cable to realize the
> transmit and receive?
>
> Best regards
>
>
> 2016-01-28 23:49 GMT+08:00 Marcus Müller :
>
>> Yes you can do that. Also, most daughterboards you can use with the N2x0
>> are full-duplex capable, so you don't even need to use two USRPs.
>>
>>
>> On 01/28/2016 04:47 PM, w xd wrote:
>>
>> Hi:
>>   Thanks so much.I want to realize the transmit and receive ofdm
>> signal in one pc.Also I want to realize the synchronization.Just combine
>> the tx_ofdm and rx_ofdm grc in one grc and just run?Any suggestion is
>> grateful.Thanks.
>>
>>
>> 2016-01-28 23:44 GMT+08:00 Marcus Müller :
>>
>>> Yes. The MIMO cable forwards the data as if it was a network cable and a
>>> switch.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 01/28/2016 04:18 PM, w xd wrote:
>>>
>>> Hi all,
>>>  I want to use one pc to control two USRP to send and receive
>>> ofdm signals synchronization in the grc.One USRP is used as transmitter and
>>> the other one is used as receive.Can it be done by just connect two usrp by
>>> mimo cable?
>>>
>>>  Thanks in advance.
>>>
>>> Best regards,
>>> zs
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> 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] Two usrp connected by mimo cable

[Marcus Müller]

Hi xd,

1. yes
2. yes, unless you have a common 10MHz reference connected to both.
That's what the MIMO cable is for.
3. the examples you're looking at.

On 01/28/2016 05:01 PM, w xd wrote:
> Thanks so much.
> 1.Is sbx support the full-duplex?
> 2.If I use one pc and one usrp to realize the transmit and
> receive.Does the frequency offset exist?
> 3.Have some related examples in grc which use one pc to control one
> usrp to realize the transmit and receive?Have some related examples in
> grc which use one pc to control two usrp connect by the mimo cable to
> realize the transmit and receive?
>
> Best regards
>
>
> 2016-01-28 23:49 GMT+08:00 Marcus Müller  >:
>
> Yes you can do that. Also, most daughterboards you can use with
> the N2x0 are full-duplex capable, so you don't even need to use
> two USRPs.
>
>
> On 01/28/2016 04:47 PM, w xd wrote:
>> Hi:
>>   Thanks so much.I want to realize the transmit and receive
>> ofdm signal in one pc.Also I want to realize the
>> synchronization.Just combine the tx_ofdm and rx_ofdm grc in one
>> grc and just run?Any suggestion is grateful.Thanks.
>>
>>
>> 2016-01-28 23:44 GMT+08:00 Marcus Müller
>> mailto:marcus.muel...@ettus.com>>:
>>
>> Yes. The MIMO cable forwards the data as if it was a network
>> cable and a switch.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 01/28/2016 04:18 PM, w xd wrote:
>>> Hi all,
>>>  I want to use one pc to control two USRP to send
>>> and receive ofdm signals synchronization in the grc.One USRP
>>> is used as transmitter and the other one is used as
>>> receive.Can it be done by just connect two usrp by mimo cable?
>>>
>>>  Thanks in advance.
>>>
>>> Best regards,
>>> zs
>>>
>>>
>>> ___
>>> 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
>>
>>
>
>

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

Re: [Discuss-gnuradio] Two usrp connected by mimo cable

[Marcus Müller]

Ah sorry ,I misread 2.
So, if you use only one USRP, then there's no frequency offset.

On 01/28/2016 05:02 PM, Marcus Müller wrote:
> Hi xd,
>
> 1. yes
> 2. yes, unless you have a common 10MHz reference connected to both.
> That's what the MIMO cable is for.
> 3. the examples you're looking at.
>
> On 01/28/2016 05:01 PM, w xd wrote:
>> Thanks so much.
>> 1.Is sbx support the full-duplex?
>> 2.If I use one pc and one usrp to realize the transmit and
>> receive.Does the frequency offset exist?
>> 3.Have some related examples in grc which use one pc to control one
>> usrp to realize the transmit and receive?Have some related examples
>> in grc which use one pc to control two usrp connect by the mimo cable
>> to realize the transmit and receive?
>>
>> Best regards
>>
>>
>> 2016-01-28 23:49 GMT+08:00 Marcus Müller > >:
>>
>> Yes you can do that. Also, most daughterboards you can use with
>> the N2x0 are full-duplex capable, so you don't even need to use
>> two USRPs.
>>
>>
>> On 01/28/2016 04:47 PM, w xd wrote:
>>> Hi:
>>>   Thanks so much.I want to realize the transmit and receive
>>> ofdm signal in one pc.Also I want to realize the
>>> synchronization.Just combine the tx_ofdm and rx_ofdm grc in one
>>> grc and just run?Any suggestion is grateful.Thanks.
>>>
>>>
>>> 2016-01-28 23:44 GMT+08:00 Marcus Müller :
>>>
>>> Yes. The MIMO cable forwards the data as if it was a network
>>> cable and a switch.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 01/28/2016 04:18 PM, w xd wrote:
 Hi all,
  I want to use one pc to control two USRP to send
 and receive ofdm signals synchronization in the grc.One
 USRP is used as transmitter and the other one is used as
 receive.Can it be done by just connect two usrp by mimo cable?

  Thanks in advance.

 Best regards,
 zs


 ___
 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
>>>
>>>
>>
>>
>

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

Re: [Discuss-gnuradio] Two usrp connected by mimo cable

[w xd]

Thanks very much.

1. If I connect two usrps by the mimo cable.Do you mean  the transmitter
and receiver also have the frequency offset if I don't use the 10MHz
reference?

2.Does the gnuradio have the related examples?

Thanks so much.Sorry for my poor english if you don't understand.Thanks so
much.

2016-01-29 0:07 GMT+08:00 w xd :

> Thanks very much.
>
> 1. If I connect two usrps by the mimo cable.Do you mean  the transmitter
> and receiver also have the frequency offset if I don't use the 10MHz
> reference?
>
> 2.Does the gnuradio have the related examples?
>
> Thanks so much.Sorry for my poor english if you don't understand.Thanks so
> much.
>
> 2016-01-29 0:03 GMT+08:00 Marcus Müller :
>
>> Ah sorry ,I misread 2.
>> So, if you use only one USRP, then there's no frequency offset.
>>
>>
>> On 01/28/2016 05:02 PM, Marcus Müller wrote:
>>
>> Hi xd,
>>
>> 1. yes
>> 2. yes, unless you have a common 10MHz reference connected to both.
>> That's what the MIMO cable is for.
>> 3. the examples you're looking at.
>>
>> On 01/28/2016 05:01 PM, w xd wrote:
>>
>> Thanks so much.
>> 1.Is sbx support the full-duplex?
>> 2.If I use one pc and one usrp to realize the transmit and receive.Does
>> the frequency offset exist?
>> 3.Have some related examples in grc which use one pc to control one usrp
>> to realize the transmit and receive?Have some related examples in grc which
>> use one pc to control two usrp connect by the mimo cable to realize the
>> transmit and receive?
>>
>> Best regards
>>
>>
>> 2016-01-28 23:49 GMT+08:00 Marcus Müller :
>>
>>> Yes you can do that. Also, most daughterboards you can use with the N2x0
>>> are full-duplex capable, so you don't even need to use two USRPs.
>>>
>>>
>>> On 01/28/2016 04:47 PM, w xd wrote:
>>>
>>> Hi:
>>>   Thanks so much.I want to realize the transmit and receive ofdm
>>> signal in one pc.Also I want to realize the synchronization.Just combine
>>> the tx_ofdm and rx_ofdm grc in one grc and just run?Any suggestion is
>>> grateful.Thanks.
>>>
>>>
>>> 2016-01-28 23:44 GMT+08:00 Marcus Müller < 
>>> marcus.muel...@ettus.com>:
>>>
 Yes. The MIMO cable forwards the data as if it was a network cable and
 a switch.

 Best regards,
 Marcus


 On 01/28/2016 04:18 PM, w xd wrote:

 Hi all,
  I want to use one pc to control two USRP to send and receive
 ofdm signals synchronization in the grc.One USRP is used as transmitter and
 the other one is used as receive.Can it be done by just connect two usrp by
 mimo cable?

  Thanks in advance.

 Best regards,
 zs


 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 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

[Discuss-gnuradio] FW: new block with python

[Yan Huang]

Hi all,

I'm building a new block by python to do sequential energy detector. In my 
python block file, I want to divide my input into different part with same 
length(number). And add the samples in each part.The python file is attached.

But when I use my block, it always print as follows:

 pn[i] += d
IndexError: list index out of range


Evey suggestion will be appreciated. Thanks in advance.

Yan




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# 
# Copyright 2016 <+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
from gnuradio import gr

class seq_ed(gr.sync_block):
"""
docstring for block seq_ed
"""
def __init__(self,number,slots,beta,alpha,noise):
	self.number=number
	self.slots=slots
	self.beta=beta
	self.alpha=alpha
	self.noise=noise
gr.sync_block.__init__(self,
name="seq_ed",
in_sig=[numpy.float32],
out_sig=[numpy.float32])

#def get_sequential_energy(self, sample):
	

def work(self, input_items, output_items):
in0 = input_items[0]
out = output_items[0]

	for i in range(0,len(in0)/self.number):		  
	pn = []
	m = i*self.number	   
	for d in in0[m: m + self.number]:  		
		pn[i] += d			   
	if pn[i] >= self.alpha:
	out[i] = 1
	elif pn[i] <= self.beta:
	out[i] = 0
	else:
	   if pn[i] >= self.noise:
		  out[i] = 1
	   else:
		  out[i] = 0
		
return len(output_items[0])

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

Re: [Discuss-gnuradio] FW: new block with python

[Marcus Müller]

Hi Yan,

pn = []

is an empty list.

pn[i] += d

tries to access an element of that list.

I'm not quite sure you should be creating a pn = [] in every for loop
iteration, neither.
This looks like a Python programming issue to me. It's probably a good
idea to practice a little bit on your python skills; python.org actually
has good Python2 tutorials!

Best regards,
Marcus

On 01/28/2016 05:22 PM, Yan Huang wrote:
>
>  
>
>  
>
>  
>
> Hi all,
>
> I'm building a new block by python to do sequential energy detector.
> In my python block file, I want to divide my input into different part
> with same length(number). And add the samples in each part.The python
> file is attached.
>
> But when I use my block, it always print as follows:
>
>  pn[i] += d
> IndexError: list index out of range
>
>
> Evey suggestion will be appreciated. Thanks in advance.
>
> Yan
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it. 
>
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
>
> ___
> 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] An End-to-End working example for GNU Radio on Zedboard

[Tim K]

Very cool. I'd be interested in looking into this further.

Am I correct in thinking that you didn't have the FPGA pass from QD to the
filters? That is to say, each block went into the FPGA, and back to the
computer?

- Tim

On Tue, Jan 26, 2016 at 2:08 PM, Alireza Khodamoradi <
ar.khodamor...@gmail.com> wrote:

> Hi everyone,
>
> I like to share our source code and some tutorials on how to implement and
> use GR on ZedBoard. You also can find custom blocks in GR designed to
> interact with XIllybus that you can use as drag and drop in GRC.
>
> https://bitbucket.org/maswes/gnuradio_on_fpga-cohort3/wiki/Home
>
> Cheers,
> Alireza
>
> ___
> 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] installing UHD using PyBOMBS 2.0

[West, Nathan]

On Thu, Jan 28, 2016 at 10:03 AM, Rob Kossler  wrote:

> Martin,
> One more thing...  Now, when I run the command "pybombs update uhd", I get
> the reply "PyBombs.RecipeListManager - ERROR - Package None has no recipe
> file!".
>

This may be my fault from this commit:
https://github.com/gnuradio/pybombs/commit/72b7bf18dea87c7e2a668f4f70be1e5f3f236975

The change on line 73 needs to be reverted and we need to check both cases
for not None, or check for not None earlier and prune the list. I'm not
familiar enough with pybombs' new architecture to see if there's a better
place to prune not None deps.

Sorry for the bug :-)


>
> Rob
>
> On Thu, Jan 28, 2016 at 9:37 AM, Rob Kossler  wrote:
>
>> Thanks for all the replies.
>>
>> Following Martin's suggestion, I added the appropriate line to
>> config.yml.  After this my install command attempted the source install,
>> but died with the same problem that my gnuradio install died yesterday --
>> problem finding boost components.  I followed Derek's suggestion to install
>> boost 1.54.  Unfortunately, that didn't fix the problem I'm having with the
>> uhd install.  (See attached txt file for details.)
>>
>> Next, I edited the boost.lwr recipe and changed all "1.53" to "1.54" and
>> all "1_53" to "1_54".  Now, the uhd install works.  I'm not sure if this
>> was the right way to fix the problem but it worked for me.
>>
>> However, I see that it installed the latest master
>> (UHD_003.010.git-0-42a3eeb6) even though I had modified the uhd recipe file
>> with the line "gitrev: tags/release_003_009_002" which is what has worked
>> for me in the past in order to get a specific version.  Perhaps the install
>> is not using the recipe file I think...
>>
>> Martin, I do have one question about the lines you suggested that I add
>> to config.yml.  Without those lines, shouldn't the command "pybombs install
>> uhd" have done a binary install? Yesterday, I found no evidence of a binary
>> install, but today I found an old version 3.5.5. I'm not sure if this
>> installed during the uhd install or when I later tried to install
>> gnuradio.  In any event, I am wondering if there is a way to configure
>> pybombs to do a binary install but to use a specific version such as 3.9.2?
>>
>> Rob
>>
>>
>> On Thu, Jan 28, 2016 at 5:18 AM, Martin Braun 
>> wrote:
>>
>>> Hey Rob,
>>>
>>> thanks for trying PyBOMBS and sorry for the lack of an announcement on
>>> usrp-users. I will announce it there once we release the next version
>>> (which will be very soon) because I've fixed some issues and also made
>>> UHD installation easier.
>>>
>>> In your case, to install UHD, do the following:
>>>
>>> 1) Create a prefix. Run one of these commands:
>>>   a) $ pybombs prefix init -a default ~/path/to/prefix
>>>   b) $ sudo pybombs prefix init -a default /usr/local
>>>
>>> The latter will put all source installs in the system, the former will
>>> put them somewhere in your home dir. For the record: Most people will
>>> want a).
>>>
>>> 2) Define this as the default prefix:
>>> $ pybombs config default_prefix default
>>>
>>> This step is not required, but if lets you skip the -p option for all
>>> following PyBOMBS commands.
>>>
>>> 3) Now comes the complicated part, which will be changed in the next
>>> version. PyBOMBS provides no defaults on which packages to install from
>>> source rather than from apt-get or whatever. You need to configure your
>>> prefix to override system defaults to source. To do this, edit the
>>> /.pybombs/config.yml file and add the lines from here:
>>>
>>> https://github.com/gnuradio/pybombs/blob/master/pybombs/skel/.pybombs/config.yml
>>>
>>> (or just copy that file there).
>>>
>>> 4) Now you can just do 'pybombs install uhd' and it will install UHD
>>> from source to your prefix. At any time, you can then 'pybombs  update
>>> uhd' to re-pull master and re-build.
>>>
>>> Hope this helps!
>>>
>>> M
>>>
>>> On 01/28/2016 12:11 AM, Rob Kossler wrote:
>>> > Hi,
>>> > I just setup a new system and as I attempted to install UHD via
>>> PyBOMBS,
>>> > I stumbled on the PyBOMBS 2.0 changeover.  Since I typically only
>>> follow
>>> > the usrp-users list and not the gnuradio list, I didn't see the
>>> > announcement of this changeover.
>>> >
>>> > I am having trouble with the install.  I really am only interested in
>>> > installing UHD (source code install), so I tried the following line,
>>> but
>>> > nothing really happened.  Afterwards, I do not see any UHD installation
>>> > in my prefix location.  Also, it is not clear to me how I would choose
>>> > whether this install should be a source install or binary install.
>>> >
>>> > $ pybombs install uhd
>>> > PyBombs.install - INFO - No packages to install.
>>> >
>>> > Any idea why the above does not seem to do anything?
>>> >
>>> >
>>> > When this didn't seem to work, I decided to go ahead and install
>>> > gnuradio since previous PyBOMBS installs of this type would also
>>> install
>>> > UHD as a source code install.  This

Re: [Discuss-gnuradio] An End-to-End working example for GNU Radio on Zedboard

[Alireza Khodamoradi]

Hi Tim,

We only put WBFM block into the FPGA. You can find more details in our
slides under "Bi-weekly Slides"

Best,
Alireza

On Thu, Jan 28, 2016 at 8:36 AM, Tim K  wrote:

> Very cool. I'd be interested in looking into this further.
>
> Am I correct in thinking that you didn't have the FPGA pass from QD to the
> filters? That is to say, each block went into the FPGA, and back to the
> computer?
>
> - Tim
>
> On Tue, Jan 26, 2016 at 2:08 PM, Alireza Khodamoradi <
> ar.khodamor...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> I like to share our source code and some tutorials on how to implement
>> and use GR on ZedBoard. You also can find custom blocks in GR designed to
>> interact with XIllybus that you can use as drag and drop in GRC.
>>
>> https://bitbucket.org/maswes/gnuradio_on_fpga-cohort3/wiki/Home
>>
>> Cheers,
>> Alireza
>>
>> ___
>> 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] installing UHD using PyBOMBS 2.0

[Seth Hitefield]

I have a fix for this I forgot to push. It checks for none when building the 
dependency list. I'll push it in the next few minutes.

-- Seth

Sent from my iPhone

> On Jan 28, 2016, at 1:02 PM, West, Nathan  wrote:
> 
>> On Thu, Jan 28, 2016 at 10:03 AM, Rob Kossler  wrote:
>> Martin,
>> One more thing...  Now, when I run the command "pybombs update uhd", I get 
>> the reply "PyBombs.RecipeListManager - ERROR - Package None has no recipe 
>> file!".
> 
> This may be my fault from this commit: 
> https://github.com/gnuradio/pybombs/commit/72b7bf18dea87c7e2a668f4f70be1e5f3f236975
> 
> The change on line 73 needs to be reverted and we need to check both cases 
> for not None, or check for not None earlier and prune the list. I'm not 
> familiar enough with pybombs' new architecture to see if there's a better 
> place to prune not None deps.
> 
> Sorry for the bug :-)
>  
>> 
>> Rob
>> 
>>> On Thu, Jan 28, 2016 at 9:37 AM, Rob Kossler  wrote:
>>> Thanks for all the replies.
>>> 
>>> Following Martin's suggestion, I added the appropriate line to config.yml.  
>>> After this my install command attempted the source install, but died with 
>>> the same problem that my gnuradio install died yesterday -- problem finding 
>>> boost components.  I followed Derek's suggestion to install boost 1.54.  
>>> Unfortunately, that didn't fix the problem I'm having with the uhd install. 
>>>  (See attached txt file for details.)
>>> 
>>> Next, I edited the boost.lwr recipe and changed all "1.53" to "1.54" and 
>>> all "1_53" to "1_54".  Now, the uhd install works.  I'm not sure if this 
>>> was the right way to fix the problem but it worked for me.
>>> 
>>> However, I see that it installed the latest master 
>>> (UHD_003.010.git-0-42a3eeb6) even though I had modified the uhd recipe file 
>>> with the line "gitrev: tags/release_003_009_002" which is what has worked 
>>> for me in the past in order to get a specific version.  Perhaps the install 
>>> is not using the recipe file I think...
>>> 
>>> Martin, I do have one question about the lines you suggested that I add to 
>>> config.yml.  Without those lines, shouldn't the command "pybombs install 
>>> uhd" have done a binary install? Yesterday, I found no evidence of a binary 
>>> install, but today I found an old version 3.5.5. I'm not sure if this 
>>> installed during the uhd install or when I later tried to install gnuradio. 
>>>  In any event, I am wondering if there is a way to configure pybombs to do 
>>> a binary install but to use a specific version such as 3.9.2?
>>> 
>>> Rob
>>> 
>>> 
 On Thu, Jan 28, 2016 at 5:18 AM, Martin Braun  
 wrote:
 Hey Rob,
 
 thanks for trying PyBOMBS and sorry for the lack of an announcement on
 usrp-users. I will announce it there once we release the next version
 (which will be very soon) because I've fixed some issues and also made
 UHD installation easier.
 
 In your case, to install UHD, do the following:
 
 1) Create a prefix. Run one of these commands:
   a) $ pybombs prefix init -a default ~/path/to/prefix
   b) $ sudo pybombs prefix init -a default /usr/local
 
 The latter will put all source installs in the system, the former will
 put them somewhere in your home dir. For the record: Most people will
 want a).
 
 2) Define this as the default prefix:
 $ pybombs config default_prefix default
 
 This step is not required, but if lets you skip the -p option for all
 following PyBOMBS commands.
 
 3) Now comes the complicated part, which will be changed in the next
 version. PyBOMBS provides no defaults on which packages to install from
 source rather than from apt-get or whatever. You need to configure your
 prefix to override system defaults to source. To do this, edit the
 /.pybombs/config.yml file and add the lines from here:
 https://github.com/gnuradio/pybombs/blob/master/pybombs/skel/.pybombs/config.yml
 
 (or just copy that file there).
 
 4) Now you can just do 'pybombs install uhd' and it will install UHD
 from source to your prefix. At any time, you can then 'pybombs  update
 uhd' to re-pull master and re-build.
 
 Hope this helps!
 
 M
 
 On 01/28/2016 12:11 AM, Rob Kossler wrote:
 > Hi,
 > I just setup a new system and as I attempted to install UHD via PyBOMBS,
 > I stumbled on the PyBOMBS 2.0 changeover.  Since I typically only follow
 > the usrp-users list and not the gnuradio list, I didn't see the
 > announcement of this changeover.
 >
 > I am having trouble with the install.  I really am only interested in
 > installing UHD (source code install), so I tried the following line, but
 > nothing really happened.  Afterwards, I do not see any UHD installation
 > in my prefix location.  Also, it is not clear to me how I would choose
 > whether this install should be a source install or binary install.
>

[Discuss-gnuradio] USRP control thread in GR block - how do I pass a USRP sptr?

[Nowlan, Sean]

I have a USRP with a GPSDO. I am working on a block that will poll a USRP for 
PPS changes in an attempt to adjust for clock offset between host and USRP. 
Assume I have explicitly set the USRP time-of-day correctly to UTC using PPS 
and a set_time_next_pps_call, and GPS is locked.

I would like to pass a USRP sink (or source) shared pointer to this block. It 
will have its own internal thread that will loop waiting for PPS edge 
transitions, polling with get_time_now, and then measuring offset between 
PC/system clock and USRP clock.

Following guidance from a mailing list thread [1], I attempted to pass a 
usrp_sink shared pointer as a basic_block_sptr and then dynamic_cast it in the 
block xtor. Here's the error I get:

clock_manager_impl.cc: In constructor 
'gr::mymodule::clock_manager_impl::clock_manager_impl(gr::basic_block_sptr, 
double, const string&)':
clock_manager_impl.cc:50:59: error: cannot dynamic_cast 'usrp' (of type 
'gr::basic_block_sptr {aka class boost::shared_ptr}') to type 
'gr::uhd::usrp_sink::sptr {aka class boost::shared_ptr}' 
(target is not pointer or reference)
 d_usrp(dynamic_cast(usrp)),

Any advice on the best way to do this? Is my approach sane?

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

Re: [Discuss-gnuradio] Message Input port in hierarchical block

[Joe K]

Kartik,

As far as I am aware, hierarchical blocks cannot process messages.  I ran
into the same issue, because I had a hierarchical block with several child
blocks, and it needed to do some control operations to the child blocks
dependent on a received message, without those blocks "understanding" or
caring about the contents of the message.

My workaround was to create a new variety of block that did nothing but
receive arbitrary messages, and then routed them back up to the hierarchical
block by calling a function in the hierarchical block.  It is kludgey, but
it works.

There are definitely use cases for having message handlers in hierarchical
blocks, but I don't know the underlying code well enough to know if it would
be straightforward to add message handling support to standard hierarchical
blocks. 

Joe

-Original Message-
Sent: Wednesday, January 27, 2016 10:46 AM
To: Discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Message Input port in hierarchical block

Hi,

I have a hierarchical block generated via GRC with no input or output
message port.
Now I add a message port by changing python code for some control
functionality using:

self.message_port_register_hier_in("test")

Now generally in sync or other blocks we can bind this "test" port to a
handler function like:

self.set_msg_handler(pmt.intern("test"),self.handler)

The problem is that there is no such function for hierarchical blocks in
gr.hier_block2 class
So how can I process message data coming in at this port ?

Please excuse if I have missed something. 

Kartik




--
View this message in context:
http://gnuradio.4.n7.nabble.com/Message-Input-port-in-hierarchical-block-tp5
7896.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
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] Message Input port in hierarchical block

[Tim O'Shea]

Hier blocks can connect to internal primitive blocks
They are removed during flattening and never receive a thread context to
handle messages in, creating a simple primitive received basic block to
handle messages like you have done is the right thing.  If we do add hier
block message handling it would likely be some clever wrapper around
creating a primitive block underneath which received a thread context like
what you have done but with some syntactic sugar.
Tim

On Thu, Jan 28, 2016, 8:36 PM Joe K  wrote:

> Kartik,
>
> As far as I am aware, hierarchical blocks cannot process messages.  I ran
> into the same issue, because I had a hierarchical block with several child
> blocks, and it needed to do some control operations to the child blocks
> dependent on a received message, without those blocks "understanding" or
> caring about the contents of the message.
>
> My workaround was to create a new variety of block that did nothing but
> receive arbitrary messages, and then routed them back up to the
> hierarchical
> block by calling a function in the hierarchical block.  It is kludgey, but
> it works.
>
> There are definitely use cases for having message handlers in hierarchical
> blocks, but I don't know the underlying code well enough to know if it
> would
> be straightforward to add message handling support to standard hierarchical
> blocks.
>
> Joe
>
> -Original Message-
> Sent: Wednesday, January 27, 2016 10:46 AM
> To: Discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] Message Input port in hierarchical block
>
> Hi,
>
> I have a hierarchical block generated via GRC with no input or output
> message port.
> Now I add a message port by changing python code for some control
> functionality using:
>
> self.message_port_register_hier_in("test")
>
> Now generally in sync or other blocks we can bind this "test" port to a
> handler function like:
>
> self.set_msg_handler(pmt.intern("test"),self.handler)
>
> The problem is that there is no such function for hierarchical blocks in
> gr.hier_block2 class
> So how can I process message data coming in at this port ?
>
> Please excuse if I have missed something.
>
> Kartik
>
>
>
>
> --
> View this message in context:
>
> http://gnuradio.4.n7.nabble.com/Message-Input-port-in-hierarchical-block-tp5
> 7896.html
> 
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP control thread in GR block - how do I pass a USRP sptr?

[Nowlan, Sean]

Oops, forgot to include a link to the reference:
[1] https://lists.gnu.org/archive/html/discuss-gnuradio/2015-03/msg00388.html


From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Nowlan, Sean
Sent: Thursday, January 28, 2016 2:34 PM
To: 'discuss-gnuradio@gnu.org' 
Subject: [Discuss-gnuradio] USRP control thread in GR block - how do I pass a 
USRP sptr?

I have a USRP with a GPSDO. I am working on a block that will poll a USRP for 
PPS changes in an attempt to adjust for clock offset between host and USRP. 
Assume I have explicitly set the USRP time-of-day correctly to UTC using PPS 
and a set_time_next_pps_call, and GPS is locked.

I would like to pass a USRP sink (or source) shared pointer to this block. It 
will have its own internal thread that will loop waiting for PPS edge 
transitions, polling with get_time_now, and then measuring offset between 
PC/system clock and USRP clock.

Following guidance from a mailing list thread [1], I attempted to pass a 
usrp_sink shared pointer as a basic_block_sptr and then dynamic_cast it in the 
block xtor. Here's the error I get:

clock_manager_impl.cc: In constructor 
'gr::mymodule::clock_manager_impl::clock_manager_impl(gr::basic_block_sptr, 
double, const string&)':
clock_manager_impl.cc:50:59: error: cannot dynamic_cast 'usrp' (of type 
'gr::basic_block_sptr {aka class boost::shared_ptr}') to type 
'gr::uhd::usrp_sink::sptr {aka class boost::shared_ptr}' 
(target is not pointer or reference)
 d_usrp(dynamic_cast(usrp)),

Any advice on the best way to do this? Is my approach sane?

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

[Discuss-gnuradio] Correlate and Sync block for square signals

[Francisco Albani]

Hi to all.

I want to test if the block Correlate and Sync improves my GFSK receiver,
so I started modifying ./gr-digital/examples/demod/test_corr_and_sync.grc .

1) I replaced the BPSK modulator (with rrc filter) by a Chunks to Symbols
[-1,+1] followed by a Interpolating FIR with gaussian taps.
2) I replaced the matched filter taps for Correlate and Sync and Polyphase
Clock Sync with the ones I think are correct BUT OBVIOUSLY ARE NOT [<--
help needed here].
3) I eliminated frequency offset and Costas Loop because I believe they are
not applicable after a FM demodulation (which I did not included in this
first exploration).

(Flowgraph attached)

Things I observe:

* Correlate and Sync detects preamble start, but the clock recovery looks
wrong (this can be seen zooming in or in the constellation plot).
* QT GUI Time sink showing correlation does not triggers with the hardcoded
value (200). I had to change it to 45.

I'm having a hard time figuring out from the c++ code and documentation the
right way to design the taps to put into Correlate and Sync and PFB Clock
Sync blocks.

I always find myself feeling I get contradictory clues from code, examples
and documentation when choosing the taps for blocks that depend on PFB.

Can you help me?

Thanks!


test_corr_and_sync_for_square_waves.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Using the viterbi decoder from gr-dtv dvbt in gr-iee802-11

[Gonzalo Arcos]

I am trying to optimize the current performance of gr-iee802-11. Ive done
some profiling and came to the conclusion that there is a lot of work being
put in decoding the convolutional code at the receiver.

I have done some research, and found out that there exists a viterbi
decoder that was developed for the digital tv branch, that supposedly
outperforms IT++ by a factor of 9x!, IT++ being the library that
gr-iee802-11 uses to decode the convolution.

When trying to adapt this decoder to gr-iee802-11 ive found some hassles.
First, the constraint length for the viterbi decoder in dvbt is K = 7,
while in gr-ieee802-11 uses a constraint length of K=5.
In addition, the generator polynomials also differ.

I would appreciate if someone could help me here, i am a beginner in the
matter of convolutional codes, i would like if someone could asses me if it
is possible to adapt this viterbi decoder to gr-iee802-11 at all, and in
case it is indeed possible, if it is very complex task for a non expert on
the matter.

The source file d_viterbi.c has a comment that says:
That changing the polynomials would need me to "regenerate the BUTTERFLY
macro calls in viterbi()" I am not certain about what should the new
parameters be for the polinomials 0133 0171.
https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using the viterbi decoder from gr-dtv dvbt in gr-iee802-11

[Gonzalo Arcos]

The dvbt project im talking about is:
https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt

And the gr-ieee-80211 project is:
https://github.com/bastibl/gr-ieee802-11

thanks in advance

2016-01-28 19:11 GMT-03:00 Gonzalo Arcos :

> I am trying to optimize the current performance of gr-iee802-11. Ive done
> some profiling and came to the conclusion that there is a lot of work being
> put in decoding the convolutional code at the receiver.
>
> I have done some research, and found out that there exists a viterbi
> decoder that was developed for the digital tv branch, that supposedly
> outperforms IT++ by a factor of 9x!, IT++ being the library that
> gr-iee802-11 uses to decode the convolution.
>
> When trying to adapt this decoder to gr-iee802-11 ive found some hassles.
> First, the constraint length for the viterbi decoder in dvbt is K = 7,
> while in gr-ieee802-11 uses a constraint length of K=5.
> In addition, the generator polynomials also differ.
>
> I would appreciate if someone could help me here, i am a beginner in the
> matter of convolutional codes, i would like if someone could asses me if it
> is possible to adapt this viterbi decoder to gr-iee802-11 at all, and in
> case it is indeed possible, if it is very complex task for a non expert on
> the matter.
>
> The source file d_viterbi.c has a comment that says:
> That changing the polynomials would need me to "regenerate the BUTTERFLY
> macro calls in viterbi()" I am not certain about what should the new
> parameters be for the polinomials 0133 0171.
> https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Correlate and Sync block for square signals

[Tom Rondeau]

On Thu, Jan 28, 2016 at 11:04 PM, Francisco Albani <
francisco.alb...@gmail.com> wrote:

> Hi to all.
>
> I want to test if the block Correlate and Sync improves my GFSK receiver,
> so I started modifying ./gr-digital/examples/demod/test_corr_and_sync.grc .
>
> 1) I replaced the BPSK modulator (with rrc filter) by a Chunks to Symbols
> [-1,+1] followed by a Interpolating FIR with gaussian taps.
> 2) I replaced the matched filter taps for Correlate and Sync and Polyphase
> Clock Sync with the ones I think are correct BUT OBVIOUSLY ARE NOT [<--
> help needed here].
> 3) I eliminated frequency offset and Costas Loop because I believe they
> are not applicable after a FM demodulation (which I did not included in
> this first exploration).
>
> (Flowgraph attached)
>
> Things I observe:
>
> * Correlate and Sync detects preamble start, but the clock recovery looks
> wrong (this can be seen zooming in or in the constellation plot).
> * QT GUI Time sink showing correlation does not triggers with the
> hardcoded value (200). I had to change it to 45.
>
> I'm having a hard time figuring out from the c++ code and documentation
> the right way to design the taps to put into Correlate and Sync and PFB
> Clock Sync blocks.
>
> I always find myself feeling I get contradictory clues from code, examples
> and documentation when choosing the taps for blocks that depend on PFB.
>
> Can you help me?
>
> Thanks!
>

Check out the test_corr_est.grc example, instead. The corr_est block was
written to replace the correlate_and_sync to improve the internal
performance issues as well as make it more applicable to other modulation
types like GMSK and GFSK. See if that example doesn't make more sense for
your situation.

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

Re: [Discuss-gnuradio] Using the viterbi decoder from gr-dtv dvbt in gr-iee802-11

[Tom Rondeau]

On Thu, Jan 28, 2016 at 11:13 PM, Gonzalo Arcos 
wrote:

> The dvbt project im talking about is:
> https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt
>
> And the gr-ieee-80211 project is:
> https://github.com/bastibl/gr-ieee802-11
>
> thanks in advance
>


We have a highly optimized Viterbi decoder for K=7, rate 1/2 in gr-fec,
which is done mostly in a VOLK kernel. Those parameters (R=1/2, K=7) are
fixed, but the polynomials can be set externally.

Tom




> 2016-01-28 19:11 GMT-03:00 Gonzalo Arcos :
>
>> I am trying to optimize the current performance of gr-iee802-11. Ive done
>> some profiling and came to the conclusion that there is a lot of work being
>> put in decoding the convolutional code at the receiver.
>>
>> I have done some research, and found out that there exists a viterbi
>> decoder that was developed for the digital tv branch, that supposedly
>> outperforms IT++ by a factor of 9x!, IT++ being the library that
>> gr-iee802-11 uses to decode the convolution.
>>
>> When trying to adapt this decoder to gr-iee802-11 ive found some hassles.
>> First, the constraint length for the viterbi decoder in dvbt is K = 7,
>> while in gr-ieee802-11 uses a constraint length of K=5.
>> In addition, the generator polynomials also differ.
>>
>> I would appreciate if someone could help me here, i am a beginner in the
>> matter of convolutional codes, i would like if someone could asses me if it
>> is possible to adapt this viterbi decoder to gr-iee802-11 at all, and in
>> case it is indeed possible, if it is very complex task for a non expert on
>> the matter.
>>
>> The source file d_viterbi.c has a comment that says:
>> That changing the polynomials would need me to "regenerate the BUTTERFLY
>> macro calls in viterbi()" I am not certain about what should the new
>> parameters be for the polinomials 0133 0171.
>> https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt
>>
>
>
> ___
> 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] Using the viterbi decoder from gr-dtv dvbt in gr-iee802-11

[Gonzalo Arcos]

Hello Tom,

Thank you for your answer.

I dont see how using the viterbi decoder from gr-fec would fix my problem.
I would still need the viterbi decoder to work on K=5 to be able to
integrate it with gr-ieee802-11, it is the same situation i am now with the
decoder i linked. My question is first if there is a highly optimized
decoder at least for 1/2 K=5, or in case it does not exist, if it is
possible for me to modify an existing implementation. I repeat, i am a
novice in the field of convolutional decoding.

Thanks


2016-01-28 20:05 GMT-03:00 Tom Rondeau :

> On Thu, Jan 28, 2016 at 11:13 PM, Gonzalo Arcos 
> wrote:
>
>> The dvbt project im talking about is:
>> https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt
>>
>> And the gr-ieee-80211 project is:
>> https://github.com/bastibl/gr-ieee802-11
>>
>> thanks in advance
>>
>
>
> We have a highly optimized Viterbi decoder for K=7, rate 1/2 in gr-fec,
> which is done mostly in a VOLK kernel. Those parameters (R=1/2, K=7) are
> fixed, but the polynomials can be set externally.
>
> Tom
>
>
>
>
>> 2016-01-28 19:11 GMT-03:00 Gonzalo Arcos :
>>
>>> I am trying to optimize the current performance of gr-iee802-11. Ive
>>> done some profiling and came to the conclusion that there is a lot of work
>>> being put in decoding the convolutional code at the receiver.
>>>
>>> I have done some research, and found out that there exists a viterbi
>>> decoder that was developed for the digital tv branch, that supposedly
>>> outperforms IT++ by a factor of 9x!, IT++ being the library that
>>> gr-iee802-11 uses to decode the convolution.
>>>
>>> When trying to adapt this decoder to gr-iee802-11 ive found some
>>> hassles. First, the constraint length for the viterbi decoder in dvbt is K
>>> = 7, while in gr-ieee802-11 uses a constraint length of K=5.
>>> In addition, the generator polynomials also differ.
>>>
>>> I would appreciate if someone could help me here, i am a beginner in the
>>> matter of convolutional codes, i would like if someone could asses me if it
>>> is possible to adapt this viterbi decoder to gr-iee802-11 at all, and in
>>> case it is indeed possible, if it is very complex task for a non expert on
>>> the matter.
>>>
>>> The source file d_viterbi.c has a comment that says:
>>> That changing the polynomials would need me to "regenerate the BUTTERFLY
>>> macro calls in viterbi()" I am not certain about what should the new
>>> parameters be for the polinomials 0133 0171.
>>> https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt
>>>
>>
>>
>> ___
>> 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] Using the viterbi decoder from gr-dtv dvbt in gr-iee802-11

[Tom Rondeau]

On Fri, Jan 29, 2016 at 12:38 AM, Gonzalo Arcos 
wrote:

> Hello Tom,
>
> Thank you for your answer.
>
> I dont see how using the viterbi decoder from gr-fec would fix my problem.
> I would still need the viterbi decoder to work on K=5 to be able to
> integrate it with gr-ieee802-11, it is the same situation i am now with the
> decoder i linked. My question is first if there is a highly optimized
> decoder at least for 1/2 K=5, or in case it does not exist, if it is
> possible for me to modify an existing implementation. I repeat, i am a
> novice in the field of convolutional decoding.
>
> Thanks
>

Apologies, I misread your first email and swapped the constraint lengths.

But no, modifying the implementation for different values of K is /not/
trivial.

Tom




> 2016-01-28 20:05 GMT-03:00 Tom Rondeau :
>
>> On Thu, Jan 28, 2016 at 11:13 PM, Gonzalo Arcos > > wrote:
>>
>>> The dvbt project im talking about is:
>>> https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt
>>>
>>> And the gr-ieee-80211 project is:
>>> https://github.com/bastibl/gr-ieee802-11
>>>
>>> thanks in advance
>>>
>>
>>
>> We have a highly optimized Viterbi decoder for K=7, rate 1/2 in gr-fec,
>> which is done mostly in a VOLK kernel. Those parameters (R=1/2, K=7) are
>> fixed, but the polynomials can be set externally.
>>
>> Tom
>>
>>
>>
>>
>>> 2016-01-28 19:11 GMT-03:00 Gonzalo Arcos :
>>>
 I am trying to optimize the current performance of gr-iee802-11. Ive
 done some profiling and came to the conclusion that there is a lot of work
 being put in decoding the convolutional code at the receiver.

 I have done some research, and found out that there exists a viterbi
 decoder that was developed for the digital tv branch, that supposedly
 outperforms IT++ by a factor of 9x!, IT++ being the library that
 gr-iee802-11 uses to decode the convolution.

 When trying to adapt this decoder to gr-iee802-11 ive found some
 hassles. First, the constraint length for the viterbi decoder in dvbt is K
 = 7, while in gr-ieee802-11 uses a constraint length of K=5.
 In addition, the generator polynomials also differ.

 I would appreciate if someone could help me here, i am a beginner in
 the matter of convolutional codes, i would like if someone could asses me
 if it is possible to adapt this viterbi decoder to gr-iee802-11 at all, and
 in case it is indeed possible, if it is very complex task for a non expert
 on the matter.

 The source file d_viterbi.c has a comment that says:
 That changing the polynomials would need me to "regenerate the
 BUTTERFLY macro calls in viterbi()" I am not certain about what should the
 new parameters be for the polinomials 0133 0171.
 https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt

>>>
>>>
>>> ___
>>> 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] Using the viterbi decoder from gr-dtv dvbt in gr-iee802-11

[Gonzalo Arcos]

Thank you for your answer Tom.

I infer from your mail that changing the value of K might as well mean
building the decoder from scratch. Which leads to my next question, is
there any tutorials on how to program a viterbi decoder for an arbitrarily
value of K in an optimized way? does anyone know? I need to be able to
increase the performance of this process.. Maybe another possibility is
stick with IT++ and use something like gpgpu to speedup the process?
What do you guys think? Do you have any suggestion?

I have my reserves about gpgpu being useful in this scenario where the
incoming packet rate is very high, and therefore the transfer of data
between the main system and the gpu would be frequent and repeated. At the
same time, im running out of ideas.

Thanks a lot for the answers so far.

2016-01-28 20:41 GMT-03:00 Tom Rondeau :

> On Fri, Jan 29, 2016 at 12:38 AM, Gonzalo Arcos 
> wrote:
>
>> Hello Tom,
>>
>> Thank you for your answer.
>>
>> I dont see how using the viterbi decoder from gr-fec would fix my
>> problem. I would still need the viterbi decoder to work on K=5 to be able
>> to integrate it with gr-ieee802-11, it is the same situation i am now with
>> the decoder i linked. My question is first if there is a highly optimized
>> decoder at least for 1/2 K=5, or in case it does not exist, if it is
>> possible for me to modify an existing implementation. I repeat, i am a
>> novice in the field of convolutional decoding.
>>
>> Thanks
>>
>
> Apologies, I misread your first email and swapped the constraint lengths.
>
> But no, modifying the implementation for different values of K is /not/
> trivial.
>
> Tom
>
>
>
>
>> 2016-01-28 20:05 GMT-03:00 Tom Rondeau :
>>
>>> On Thu, Jan 28, 2016 at 11:13 PM, Gonzalo Arcos <
>>> gonzaloarco...@gmail.com> wrote:
>>>
 The dvbt project im talking about is:
 https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt

 And the gr-ieee-80211 project is:
 https://github.com/bastibl/gr-ieee802-11

 thanks in advance

>>>
>>>
>>> We have a highly optimized Viterbi decoder for K=7, rate 1/2 in gr-fec,
>>> which is done mostly in a VOLK kernel. Those parameters (R=1/2, K=7) are
>>> fixed, but the polynomials can be set externally.
>>>
>>> Tom
>>>
>>>
>>>
>>>
 2016-01-28 19:11 GMT-03:00 Gonzalo Arcos :

> I am trying to optimize the current performance of gr-iee802-11. Ive
> done some profiling and came to the conclusion that there is a lot of work
> being put in decoding the convolutional code at the receiver.
>
> I have done some research, and found out that there exists a viterbi
> decoder that was developed for the digital tv branch, that supposedly
> outperforms IT++ by a factor of 9x!, IT++ being the library that
> gr-iee802-11 uses to decode the convolution.
>
> When trying to adapt this decoder to gr-iee802-11 ive found some
> hassles. First, the constraint length for the viterbi decoder in dvbt is K
> = 7, while in gr-ieee802-11 uses a constraint length of K=5.
> In addition, the generator polynomials also differ.
>
> I would appreciate if someone could help me here, i am a beginner in
> the matter of convolutional codes, i would like if someone could asses me
> if it is possible to adapt this viterbi decoder to gr-iee802-11 at all, 
> and
> in case it is indeed possible, if it is very complex task for a non expert
> on the matter.
>
> The source file d_viterbi.c has a comment that says:
> That changing the polynomials would need me to "regenerate the
> BUTTERFLY macro calls in viterbi()" I am not certain about what should the
> new parameters be for the polinomials 0133 0171.
> https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt
>


 ___
 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] Using the viterbi decoder from gr-dtv dvbt in gr-iee802-11

[Tom Rondeau]

On Fri, Jan 29, 2016 at 12:52 AM, Gonzalo Arcos 
wrote:

> Thank you for your answer Tom.
>
> I infer from your mail that changing the value of K might as well mean
> building the decoder from scratch. Which leads to my next question, is
> there any tutorials on how to program a viterbi decoder for an arbitrarily
> value of K in an optimized way? does anyone know? I need to be able to
> increase the performance of this process.. Maybe another possibility is
> stick with IT++ and use something like gpgpu to speedup the process?
> What do you guys think? Do you have any suggestion?
>
> I have my reserves about gpgpu being useful in this scenario where the
> incoming packet rate is very high, and therefore the transfer of data
> between the main system and the gpu would be frequent and repeated. At the
> same time, im running out of ideas.
>
> Thanks a lot for the answers so far.
>

Check out the Spiral Project:

http://www.spiral.net/software/viterbi.html

Tom



> 2016-01-28 20:41 GMT-03:00 Tom Rondeau :
>
>> On Fri, Jan 29, 2016 at 12:38 AM, Gonzalo Arcos > > wrote:
>>
>>> Hello Tom,
>>>
>>> Thank you for your answer.
>>>
>>> I dont see how using the viterbi decoder from gr-fec would fix my
>>> problem. I would still need the viterbi decoder to work on K=5 to be able
>>> to integrate it with gr-ieee802-11, it is the same situation i am now with
>>> the decoder i linked. My question is first if there is a highly optimized
>>> decoder at least for 1/2 K=5, or in case it does not exist, if it is
>>> possible for me to modify an existing implementation. I repeat, i am a
>>> novice in the field of convolutional decoding.
>>>
>>> Thanks
>>>
>>
>> Apologies, I misread your first email and swapped the constraint lengths.
>>
>> But no, modifying the implementation for different values of K is /not/
>> trivial.
>>
>> Tom
>>
>>
>>
>>
>>> 2016-01-28 20:05 GMT-03:00 Tom Rondeau :
>>>
 On Thu, Jan 28, 2016 at 11:13 PM, Gonzalo Arcos <
 gonzaloarco...@gmail.com> wrote:

> The dvbt project im talking about is:
> https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt
>
> And the gr-ieee-80211 project is:
> https://github.com/bastibl/gr-ieee802-11
>
> thanks in advance
>


 We have a highly optimized Viterbi decoder for K=7, rate 1/2 in gr-fec,
 which is done mostly in a VOLK kernel. Those parameters (R=1/2, K=7) are
 fixed, but the polynomials can be set externally.

 Tom




> 2016-01-28 19:11 GMT-03:00 Gonzalo Arcos :
>
>> I am trying to optimize the current performance of gr-iee802-11. Ive
>> done some profiling and came to the conclusion that there is a lot of 
>> work
>> being put in decoding the convolutional code at the receiver.
>>
>> I have done some research, and found out that there exists a viterbi
>> decoder that was developed for the digital tv branch, that supposedly
>> outperforms IT++ by a factor of 9x!, IT++ being the library that
>> gr-iee802-11 uses to decode the convolution.
>>
>> When trying to adapt this decoder to gr-iee802-11 ive found some
>> hassles. First, the constraint length for the viterbi decoder in dvbt is 
>> K
>> = 7, while in gr-ieee802-11 uses a constraint length of K=5.
>> In addition, the generator polynomials also differ.
>>
>> I would appreciate if someone could help me here, i am a beginner in
>> the matter of convolutional codes, i would like if someone could asses me
>> if it is possible to adapt this viterbi decoder to gr-iee802-11 at all, 
>> and
>> in case it is indeed possible, if it is very complex task for a non 
>> expert
>> on the matter.
>>
>> The source file d_viterbi.c has a comment that says:
>> That changing the polynomials would need me to "regenerate the
>> BUTTERFLY macro calls in viterbi()" I am not certain about what should 
>> the
>> new parameters be for the polinomials 0133 0171.
>> https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/lib/dvbt
>>
>
>
> ___
> 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

[Discuss-gnuradio] Trace Plotter

[Tech]

I'm looking for a GRC module like the scope except I need it to plot a
single network packet per update. Basically, the network packet has an
FFT result in it so I just need to plot each packet payload as they
arrive.

Please let me know if something like this already exists.

Thanks,
Clark

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

Re: [Discuss-gnuradio] Trace Plotter

[Marcus D. Leech]

On 01/28/2016 08:11 PM, Tech wrote:

I'm looking for a GRC module like the scope except I need it to plot a
single network packet per update. Basically, the network packet has an
FFT result in it so I just need to plot each packet payload as they
arrive.

Please let me know if something like this already exists.

Thanks,
Clark

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

There's a vector sink in Qt GUI


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

[Discuss-gnuradio] USRP block to receive signal periodically

[Zhihong Luo]

Hi all,

I just started to use GNU Radio for testing on USRP, and I want to make the
USRP receive signal periodically.  So that for example, it will receive for
half a second, then rest for 10 seconds, during which it won't  request
data from USRP.

I previously used GRC, but the usrp sink block doesn't have this function.
So I may need to write a custom C OOT block. Can you give me a clue on how
to do this? Because I didn't find example specifically for usrp on the
website.

Thanks a lot.

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

Re: [Discuss-gnuradio] Noise Source Output ~3dB Higher on E310?

[John Malsbury]

Thanks guys.

On Tue, Jan 26, 2016 at 8:51 AM, Philip Balister 
wrote:

> On 01/26/2016 05:17 PM, Tomaž Šolc wrote:
> > On 26. 01. 2016 12:14, Philip Balister wrote:
> >> On 01/26/2016 11:35 AM, John Malsbury wrote:
> >>> This was a surprising one.  When set with a the same seed (regardless
> of
> >>> value) and amplitude, the noise source (gaussian) seems to have 3 dB
> higher
> >>> power when running on E310 vs. an i7 platform.
> >>>
> >>> (GNU Radio commit 8220b79653c6c7999a18fed075bdb1c41bca0613 on i7)
> >>>
> >>> (e3xx release 3 from here:
> >>> http://files.ettus.com/e3xx_images/e3xx-release-3/)
> >>
> >> Release 3 has 3.7.7.1 which does not have the fix for this problem.
> >
> > Just in case anyone else is wondering, I'm guessing that Philip is
> > talking about this commit:
> >
> >
> https://github.com/gnuradio/gnuradio/commit/5335005bcfbd671a0760bde08e69ef867b7ffc24
>
> Thanks. I'm at the hackfest and realized there was some out of band info
> needed to complete my answer after hitting send.
>
> Philip
>
> >
> > Regards
> > Tomaž
> >
> > ___
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio