[Discuss-gnuradio] GNURadio 3.7 on IGEPv2 Board (Ubuntu Linaro)

[Luigi Picari]

Dear All,

I Installed 
gnuradio-3.7.0rc0in
Ubuntu Linaro 12.04.2 LTS (OMAP3 Board - IGEPv2).

uname -a
Linux linaro-ubuntu-desktop 2.6.37+ #2 Mon Feb 13 13:22:25 CET 2012 armv7l
armv7l armv7l GNU/Linux

I used these commands to compile and everything went well:
cmake -DENABLE_BAD_BOOST=ON ../
make
sudo make install

If I try 'make test' the board fails the first and it remains stalled on
the second:
Start   1: qa_volk_test_all
  1/174 Test   #1: qa_volk_test_all .***Failed5.56 sec
Start   2: gr-runtime-test

If I try to execute a simple code Signal Source --> Multiply Const -->
Audio Sink (http://nopaste.info/647932116a.html)I get this error:
  File "./Segnale_Audio_NO_GUI.py", line 14, in 
from gnuradio.gr import firdes
ImportError: cannot import name firdes

Can someone help me to understand where I'm wrong?

Luigi




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

Re: [Discuss-gnuradio] GNURadio 3.7 on IGEPv2 Board (Ubuntu Linaro)

[Tom Rondeau]

On Wed, Jul 3, 2013 at 5:35 AM, Luigi Picari  wrote:
> Dear All,
>
> I Installed gnuradio-3.7.0rc0 in Ubuntu Linaro 12.04.2 LTS (OMAP3 Board -
> IGEPv2).
>
> uname -a
> Linux linaro-ubuntu-desktop 2.6.37+ #2 Mon Feb 13 13:22:25 CET 2012 armv7l
> armv7l armv7l GNU/Linux
>
> I used these commands to compile and everything went well:
> cmake -DENABLE_BAD_BOOST=ON ../
> make
> sudo make install
>
> If I try 'make test' the board fails the first and it remains stalled on the
> second:
> Start   1: qa_volk_test_all
>   1/174 Test   #1: qa_volk_test_all .***Failed5.56 sec
> Start   2: gr-runtime-test

Run 'ctest -V -R volk' and post the output to help us figure out
what's going wrong there.

> If I try to execute a simple code Signal Source --> Multiply Const --> Audio
> Sink (http://nopaste.info/647932116a.html)I get this error:
>   File "./Segnale_Audio_NO_GUI.py", line 14, in 
> from gnuradio.gr import firdes
> ImportError: cannot import name firdes
>
> Can someone help me to understand where I'm wrong?
>
> Luigi

You're using 3.7, which changed the structure of the modules. The
'firdes' Python module is now underneath the 'filter' module. So you
have to make sure you do:

from gnuradio import filter
from gnuradio.filter import firdes

You can now use 'filter.firdes' or just 'firdes...'.

Tom

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

Re: [Discuss-gnuradio] Proper use of scoped_lock in out-of-tree module?

[Tom Rondeau]

On Wed, Jul 3, 2013 at 1:40 AM, Monahan-Mitchell, Tim
 wrote:
> Ø  The associated mutex is usually a (private) member variable of a class,
> and is used as a synchronization object by different class methods.  As a
> member variable, you have a choice to name it whatever you want.  If the
> mutex is the only one in the class, we usually call it d_mutex.  If there is
> more than one mutex in the class, then we give it a unique name.
>
> Ø  If you're writing your own code as a class, making the mutex a member
> variable and calling it d_mutex, and calling the local scoped lock object
> 'guard', is probably the most descriptive, but again, it's up to you.
>
> OK, that helps, thanks.
>
>
>
> One additional question – looking file_meta_source_impl.cc, it uses
> ‘d_mutex’ in all cases; in most places in the file, the object is called
> ‘guard(d_mutex)’. But in one place the object is called ‘lock(d_mutex)’… Is
> that a mistake?

Just an oversight, possibly put in a different time. It doesn't matter
because the variable guard and lock are in different scopes and exist
at different times. It's a local name, and each time we created a
scoped_lock, we could have named it something else (guard0, guard1,
guard2). No reason that they need to be the same and no reason for
them to be different.

> I got concerned when I read some about this on the net, saying that it is
> easy to forget that a local object will get destroyed when the scope that
> created it closes. Hence the need for d_mutex to get defined as a private
> class member (but it compiles fine if that step is forgotten).

Yes, exactly. The scoped_lock variable is local. It uses d_mutex to
lock the mutex during its own lifetime. When the variable goes out of
scope, d_mutex is unlocked and another call to scoped_lock can now
acquire it.

>
> Tim

Tom

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

Re: [Discuss-gnuradio] FM Mod / Demod Sensitivity and Quad. Gain Parameters

[Tom Rondeau]

On Thu, Jun 27, 2013 at 3:54 PM, Dan CaJacob  wrote:
> We use the FM Mod and Quadrature Demod blocks to modulate and demodulate
> GFSK packetized data.  In the past, we have used sensitivity values for
> these blocks that were provided for us, but their meaning was opaque.
>
> I did some digging in the list and the web and found two prevalent
> definitions for sensitivity from examples.  Both definitions were consistent
> in saying that the Demod parameter 'Quadrature Gain' should be the inverse
> of the sensitivity parameter for the Mod block.
>
> The competing definitions for sensitivity were:
>
> 1. sensitivity = (pi / 2) / samples_pr_symbol  # from
> gnuradio/blksimpl/gmsk.py
>
> and
>
> 2. sensitivity = 2 * pi * max_deviation / sample_rate  # from
> gnuradio/blks2impl/nbfm_tx.py
>
> In my own recent work, I have been using the second definition because it
> seems to work and it gives me control over the deviation (I define max
> deviation using modulation index and baud rate).
>
> However, when I attempt to use 1/sensitivity for the Quadrature Gain of the
> RX, it does not seem to work, while altering the RX definition of
> sensitivity to be 1 / (2 * pi * max_deviation / baud_rate) does seem to
> work.
>
> Am I missing something fundamental about how these parameters work?

Hi Dan,

The quadrature_demod converts from phase/frequency modulation back to
amplitude. So in the case of FSK signals (and let's treat GMSK as FSK
for this), we want to convert frequency f1 into -1 and frequeuncy f2
to +1. Also, "let's assume the system is synchronized" so that f1 =
-fm and f2 = +fm. What you want to do is convert those frequencies to
-1's and 1's, right? So there's some rotation around the unit circle
that maps to this based on the number of samples per symbol you are
using. So hopefully that explains where the pi and sps in the
calculations come from.

Hope this helps.

Tom

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

Re: [Discuss-gnuradio] Bug in volk on armv6

[Tom Rondeau]

On Mon, Jul 1, 2013 at 4:08 AM, Alexey Bazhin  wrote:
> Hi!
>
> I would like to report a bug in volk on armv6.
>
> There is infinite "while" cycle in volk/tmpl/volk_cpu.tmpl.c function
> "has_neon" (line 111).
>
> Code "while(!found_neon && auxvec_f) {" will loop infinitely if there
> is no neon in platform. found_neon will never be true and file
> descriptor auxvec_f will always be true.
>
> --
> Alexey Bazhin 

Ok, I see your point. Looks like we should be testing the return value
from fread, instead of auxvec_f. Can you confirm if this patch works?

diff --git a/volk/tmpl/volk_cpu.tmpl.c b/volk/tmpl/volk_cpu.tmpl.c
index 81fc679..b1a0a4a 100644
--- a/volk/tmpl/volk_cpu.tmpl.c
+++ b/volk/tmpl/volk_cpu.tmpl.c
@@ -116,10 +116,11 @@ static int has_neon(void){
 auxvec_f = fopen("/proc/self/auxv", "rb");
 if(!auxvec_f) return 0;

+size_t r = 1;
 //so auxv is basically 32b of ID and 32b of value
 //so it goes like this
-while(!found_neon && auxvec_f) {
-  fread(auxvec, sizeof(unsigned long), 2, auxvec_f);
+while(!found_neon && r) {
+  r = fread(auxvec, sizeof(unsigned long), 2, auxvec_f);
   if((auxvec[0] == AT_HWCAP) && (auxvec[1] & HWCAP_NEON))
 found_neon = 1;
 }

Or might be better to test 'if(r < 2)' after the fread line and break
in case an error occurs and we only get 1 character out and not try to
read from it again. Probably not a bit deal since we're only reading
in two chars at a time.

Tom

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

Re: [Discuss-gnuradio] Proper use of scoped_lock in out-of-tree module?

[Johnathan Corgan]

On 07/02/2013 10:40 PM, Monahan-Mitchell, Tim wrote:

> I got concerned when I read some about this on the net, saying that it
> is easy to forget that a local object will get destroyed when the scope
> that created it closes. Hence the need for d_mutex to get defined as a
> private class member (but it compiles fine if that step is forgotten).

Just to be clear, there are two variables here. The 'd_mutex' is a class
variable, usually private (but doesn't have to be.) It serves as a
common synchronization object to allow multiple threads to coordinate
use of some resource, over the lifetime of a class instance, by being
locked and unlocked as needed by class methods.

The other variable, 'guard' or 'lock' or 'l', is the thing doing the
locking in individual methods that must synchronize access.  As a scoped
lock, it is designed to lock the mutex given as a constructor parameter
when it is created, and unlock that mutex when it goes out of scope and
is destroyed.  The common pattern, then, is to make it a local variable
in a method, so that it goes in and out of scope (and acquires and
releases the mutex) automatically, while the code within that scope can
assume it is holding the lock exclusively to any other thread.

Since this is a variable and not some language keyword, you can name it
whatever you like.  'guard' is common, but it doesn't have to be the
same each time it is used.

What specifically do you mean when you say 'compiles fine if that step
is forgotten' ?

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com



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

Re: [Discuss-gnuradio] edit packet content in benchmark

[Tom Rondeau]

On Mon, Jun 24, 2013 at 12:08 PM, yeran  wrote:
> Hi everyone,
>
> In benchmark, the packet is 23-byte long, inclues preamble, access code,
> header, payload, crc, and 'x55'. Now I want to add a one-byte flag after the
> header. I changed the packet_utils.py make_packet block, add a flag when
> form the new packet. And changed the header length to 9.  However, in
> terminal, when I run benchmark, it shows the new packet is 24-byte long now,
> including the flag byte. But in the file_sink after the byte2chunks and the
> chunks2symbols, the file is not longer than before. In these two files a
> packet is still 23 bytes without the new flag byte. So though in tx
> terminal, it looks like I've successfully changed the packet format, but
> actually, the transmitter didn't send this out, it still sends the original
> packet format.
>
> Has anyone come across this problem before, and could give me some kind
> suggestions on this? Thanks in advance!
>
> Ada

In the receiver, the deframing strips the header, so you're only
getting the payload out. You'll need to look at what the receiver code
is doing to read the header and return the packet length. You can
update that code to also include your flag from the header.

Tom

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

Re: [Discuss-gnuradio] A basic but critical problem in stopping of python code

[Tom Rondeau]

On Sun, Jun 23, 2013 at 3:29 AM, bojiechen  wrote:
>  When run a python script file, as we know main function will be run first.
> We send the class to a object "tb",for instance,we use tb.start or tb.run.
>
> but if we want to stop a flawgraph and reconfiguration.we must use tb.stop
> with tb.wait and then restart tb.when I use this ,the tb.wait() can not
>
> finish . I don`t know why. even I use tb.lock() and tb.unlock() it doesn`t

If you are reconfiguring the flowgraph, just use:

tb.lock()
(Put your disconnect and connect lines here)
tb.unlock()

That should be all.

> work too. I take this test in tunnel.py.

Don't use tunnel.py. It's probably not completing something and
staying in a deadlock state.

Tom

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

[Discuss-gnuradio] GNU Radio release 3.7.0 available for download

[Johnathan Corgan]

GNU Radio release 3.7.0 is available for download:

http://gnuradio.org/releases/gnuradio/gnuradio-3.7.0.tar.gz

MD5 sum:

c2856ee14b415a64abf5dc9af0f5374c  gnuradio-3.7.0.tar.gz

This is a major new release of GNU Radio, culminating a year and a half
of side-by-side development with the new features added to the GNU Radio
3.6 API. With the significant restructuring that was occurring as part
of the 3.7 development, at times this seemed like rebuilding a race car
engine while still driving it.

All the appropriate bug fixes applied in the 3.6.0 - 3.6.5.1 series of
releases were incorporated into 3.7.0 and are not re-listed here.
Otherwise, this release has all the features added to 3.6 and the new
ones listed below that could only be done in the 3.7 API.

The GNU Radio SDR framework/runtime gained many new capabilities in 3.6,
and our project focus now during the 3.7 development series will be to
use these new capabilities to improve GNU Radio DSP block libraries and
example applications.

The detailed release notes follow.


Contributors:

Ben Reynwar 
Gerald Baier 
Jaroslav Škarvada 
Jeff Long 
Johnathan Corgan 
Josh Blum 
Mark Plett 
Martin Braun 
Michael Dickens 
Nicholas Corgan 
Nick Foster 
Nick McCarthy 
Philip Balister 
Sreeraj Rajendran 
Tim Newman 
Tim O'Shea 
Tom Rondeau 
Volker Schroer 


Code Structure Changes (Johnathan Corgan, Tom Rondeau)

The GNU Radio source code was restructured and flattened. All top-level
components now use the same structure for consistency and ease of use.
All blocks were moved out of gnuradio-core, which has been renamed to
gnuradio-runtime. The blocks are now in their appropriate top-level
components and reimplemented with the new 3.7 API style. The new API
makes use of C++ namespaces and the virtual private implementation class
pattern to better hide GNU Radio internals from user code.

Details about this can be found here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7

A Google doc showing all items that were moved from one place to another
in the new style is here:

http://ow.ly/mDpey

Blocks not listed were already in their own components. Many blocks were
removed. All columns marked with ‘-’ means that column is not
applicable to that block or class. Any column (except those marked as
Remove) that are blank means that we might be able to improve upon it,
which normally indicates using VOLK or improving documentation.

A Google doc showing the new component and Doxygen categories for all
components is here:

http://ow.ly/mDplO


Important new features:

ControlPort (Tom Rondeau, Tim O’Shea)

ControlPort is a new interface for standardizing remote procedure calls
in GNU Radio:

* Remote control and visualization.
* Use of ControlPort to debug without requiring extra debug streams.
* Abstracted interface, but currently using ICE (www.zeroc.com).
* No additional CPU usage while no monitoring is occurring.
* Can connect multiple remotes to same GNU Radio application.
* Can also have single ControlPort app control multiple GR apps.

Each block creates interfaces to control data members, by defining ‘get’
and ‘set’ interface to query and update values of block variables.
Preference files control the state of ControlPort in section
[ControlPort] of gnuradio-runtime.conf.

ControlPort comes with a generic utility to allow you to see all
interfaces of a flowgraph:

* gr-ctrlport-monitor  -p 

Within a flowgraph, one can also use ControlPort probes to pass vectors
of data to a ControlPort client, including complex IQ data. One useful
probe calculates the power spectral density of a block output for remote
display.

See the ControlPort page in the GNU Radio manual for more information:

http://gnuradio.org/doc/doxygen/page_ctrlport.html


Performance Measurement Tools

Performance Counters were first built into GNU Radio in 3.6.5, but could
only be accessed locally. Now, all Performance Counters can be exported
over ControlPort.

Performance Counters must be compiled into GNU Radio using
-DENABLE_PERFORMANCE_COUNTERS=True. They can be toggled on/off at
runtime using the [PerfCounters] section in gnuradio-runtime.conf. Use
option ‘export’ to export Performance Counters over ControlPort.

We now include a new tool to visualize the Performance Counters over
ControlPort. This is installed as gr-perf-monitorx and requires the
Python modules Scipy, NetworkX, and Matplotlib. Nodes of the flowgraph
are represented as blue squares. The size of the square is proportional
to the amount of time spent in the work function (either thread time or
monotonic (wall clock) time). The size and depth of the shade of red of
the edges is proportional to how full the block’s output buffer is.


QTGUI Enhancements (Tom Rondeau, Nick Foster, Ben Reynwar)

The QTGUI widgets defined in gr-qtgui have had a major overhaul in 3.7.
All plots are now split out into individual components, including:

* Time plots (amplitude versus time)
* FFT plots (or PSD) (log magnitude versus 

Re: [Discuss-gnuradio] GNU Radio release 3.7.0 available for download

[LD Zhang]

Is it true that the blks2 is gotten rid of in 3.7? I have gotten used to some 
code that uses blks2 and some documentation. Will those online 
documentation/code examples also be updated with version 3.7?

We are getting a new USRP, should I stick with 3.6 or go to 3.7?

Thanks,

LD

-Original Message-
From: discuss-gnuradio-bounces+ldz10565=gmail@gnu.org 
[mailto:discuss-gnuradio-bounces+ldz10565=gmail@gnu.org] On Behalf Of 
Johnathan Corgan
Sent: Wednesday, July 03, 2013 12:03 PM
To: Discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] GNU Radio release 3.7.0 available for download

GNU Radio release 3.7.0 is available for download:

http://gnuradio.org/releases/gnuradio/gnuradio-3.7.0.tar.gz

MD5 sum:

c2856ee14b415a64abf5dc9af0f5374c  gnuradio-3.7.0.tar.gz

This is a major new release of GNU Radio, culminating a year and a half of 
side-by-side development with the new features added to the GNU Radio
3.6 API. With the significant restructuring that was occurring as part of the 
3.7 development, at times this seemed like rebuilding a race car engine while 
still driving it.

All the appropriate bug fixes applied in the 3.6.0 - 3.6.5.1 series of releases 
were incorporated into 3.7.0 and are not re-listed here.
Otherwise, this release has all the features added to 3.6 and the new ones 
listed below that could only be done in the 3.7 API.

The GNU Radio SDR framework/runtime gained many new capabilities in 3.6, and 
our project focus now during the 3.7 development series will be to use these 
new capabilities to improve GNU Radio DSP block libraries and example 
applications.

The detailed release notes follow.


Contributors:

Ben Reynwar 
Gerald Baier  Jaroslav Škarvada 
 Jeff Long  Johnathan Corgan 
 Josh Blum  Mark Plett 
 Martin Braun  Michael Dickens 
 Nicholas Corgan  Nick Foster 
 Nick McCarthy  Philip Balister 
 Sreeraj Rajendran  Tim Newman 
 Tim O'Shea  Tom Rondeau 
 Volker Schroer 


Code Structure Changes (Johnathan Corgan, Tom Rondeau)

The GNU Radio source code was restructured and flattened. All top-level 
components now use the same structure for consistency and ease of use.
All blocks were moved out of gnuradio-core, which has been renamed to 
gnuradio-runtime. The blocks are now in their appropriate top-level components 
and reimplemented with the new 3.7 API style. The new API makes use of C++ 
namespaces and the virtual private implementation class pattern to better hide 
GNU Radio internals from user code.

Details about this can be found here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7

A Google doc showing all items that were moved from one place to another in the 
new style is here:

http://ow.ly/mDpey

Blocks not listed were already in their own components. Many blocks were 
removed. All columns marked with ‘-’ means that column is not applicable to 
that block or class. Any column (except those marked as
Remove) that are blank means that we might be able to improve upon it, which 
normally indicates using VOLK or improving documentation.

A Google doc showing the new component and Doxygen categories for all 
components is here:

http://ow.ly/mDplO


Important new features:

ControlPort (Tom Rondeau, Tim O’Shea)

ControlPort is a new interface for standardizing remote procedure calls in GNU 
Radio:

* Remote control and visualization.
* Use of ControlPort to debug without requiring extra debug streams.
* Abstracted interface, but currently using ICE (www.zeroc.com).
* No additional CPU usage while no monitoring is occurring.
* Can connect multiple remotes to same GNU Radio application.
* Can also have single ControlPort app control multiple GR apps.

Each block creates interfaces to control data members, by defining ‘get’
and ‘set’ interface to query and update values of block variables.
Preference files control the state of ControlPort in section [ControlPort] of 
gnuradio-runtime.conf.

ControlPort comes with a generic utility to allow you to see all interfaces of 
a flowgraph:

* gr-ctrlport-monitor  -p 

Within a flowgraph, one can also use ControlPort probes to pass vectors of data 
to a ControlPort client, including complex IQ data. One useful probe calculates 
the power spectral density of a block output for remote display.

See the ControlPort page in the GNU Radio manual for more information:

http://gnuradio.org/doc/doxygen/page_ctrlport.html


Performance Measurement Tools

Performance Counters were first built into GNU Radio in 3.6.5, but could only 
be accessed locally. Now, all Performance Counters can be exported over 
ControlPort.

Performance Counters must be compiled into GNU Radio using 
-DENABLE_PERFORMANCE_COUNTERS=True. They can be toggled on/off at runtime using 
the [PerfCounters] section in gnuradio-runtime.conf. Use option ‘export’ to 
export Performance Counters over ControlPort.

We now include a new tool to visualize the Performance Counters over 
ControlPort. This is installed as gr-perf-monitorx and requi

Re: [Discuss-gnuradio] GNU Radio release 3.7.0 available for download

[Johnathan Corgan]

On Wed, Jul 3, 2013 at 12:57 PM, LD Zhang  wrote:


> Is it true that the blks2 is gotten rid of in 3.7? I have gotten used to
> some code that uses blks2 and some documentation. Will those online
> documentation/code examples also be updated with version 3.7?
>

All of the functionality that was in the blks2 python namespace has been
moved to other top-level components, such as gr-digital or gr-analog, and
the example code that used it has also been modified accordingly.

 We are getting a new USRP, should I stick with 3.6 or go to 3.7?
>

All of the features in GNU Radio that support the USRP hardware (via
gr-uhd) are available in either 3.6.5.1 or 3.7.0.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio release 3.7.0 available for download

[Tom Rondeau]

On Wed, Jul 3, 2013 at 3:57 PM, LD Zhang  wrote:
> Is it true that the blks2 is gotten rid of in 3.7? I have gotten used to some 
> code that uses blks2 and some documentation. Will those online 
> documentation/code examples also be updated with version 3.7?
>
> We are getting a new USRP, should I stick with 3.6 or go to 3.7?
>
> Thanks,
>
> LD

All of the blocks in blks2impl are still there but are now in their
more natural components. Look for them under the python/ directory for
different top-level components. Specifically, you'll find many in
gr-digital, gr-analog, and gr-filter.

This wiki is designed to help people transition over to the new code.
Help in documenting where some of these blocks went would be very
welcome:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7

Tom


>
> -Original Message-
> From: discuss-gnuradio-bounces+ldz10565=gmail@gnu.org 
> [mailto:discuss-gnuradio-bounces+ldz10565=gmail@gnu.org] On Behalf Of 
> Johnathan Corgan
> Sent: Wednesday, July 03, 2013 12:03 PM
> To: Discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] GNU Radio release 3.7.0 available for download
>
> GNU Radio release 3.7.0 is available for download:
>
> http://gnuradio.org/releases/gnuradio/gnuradio-3.7.0.tar.gz
>
> MD5 sum:
>
> c2856ee14b415a64abf5dc9af0f5374c  gnuradio-3.7.0.tar.gz
>
> This is a major new release of GNU Radio, culminating a year and a half of 
> side-by-side development with the new features added to the GNU Radio
> 3.6 API. With the significant restructuring that was occurring as part of the 
> 3.7 development, at times this seemed like rebuilding a race car engine while 
> still driving it.
>
> All the appropriate bug fixes applied in the 3.6.0 - 3.6.5.1 series of 
> releases were incorporated into 3.7.0 and are not re-listed here.
> Otherwise, this release has all the features added to 3.6 and the new ones 
> listed below that could only be done in the 3.7 API.
>
> The GNU Radio SDR framework/runtime gained many new capabilities in 3.6, and 
> our project focus now during the 3.7 development series will be to use these 
> new capabilities to improve GNU Radio DSP block libraries and example 
> applications.
>
> The detailed release notes follow.
>
>
> Contributors:
>
> Ben Reynwar 
> Gerald Baier  Jaroslav Škarvada 
>  Jeff Long  Johnathan Corgan 
>  Josh Blum  Mark Plett 
>  Martin Braun  Michael Dickens 
>  Nicholas Corgan  Nick Foster 
>  Nick McCarthy  Philip Balister 
>  Sreeraj Rajendran  Tim Newman 
>  Tim O'Shea  Tom Rondeau 
>  Volker Schroer 
>
>
> Code Structure Changes (Johnathan Corgan, Tom Rondeau)
>
> The GNU Radio source code was restructured and flattened. All top-level 
> components now use the same structure for consistency and ease of use.
> All blocks were moved out of gnuradio-core, which has been renamed to 
> gnuradio-runtime. The blocks are now in their appropriate top-level 
> components and reimplemented with the new 3.7 API style. The new API makes 
> use of C++ namespaces and the virtual private implementation class pattern to 
> better hide GNU Radio internals from user code.
>
> Details about this can be found here:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7
>
> A Google doc showing all items that were moved from one place to another in 
> the new style is here:
>
> http://ow.ly/mDpey
>
> Blocks not listed were already in their own components. Many blocks were 
> removed. All columns marked with ‘-’ means that column is not applicable 
> to that block or class. Any column (except those marked as
> Remove) that are blank means that we might be able to improve upon it, which 
> normally indicates using VOLK or improving documentation.
>
> A Google doc showing the new component and Doxygen categories for all 
> components is here:
>
> http://ow.ly/mDplO
>
>
> Important new features:
>
> ControlPort (Tom Rondeau, Tim O’Shea)
>
> ControlPort is a new interface for standardizing remote procedure calls in 
> GNU Radio:
>
> * Remote control and visualization.
> * Use of ControlPort to debug without requiring extra debug streams.
> * Abstracted interface, but currently using ICE (www.zeroc.com).
> * No additional CPU usage while no monitoring is occurring.
> * Can connect multiple remotes to same GNU Radio application.
> * Can also have single ControlPort app control multiple GR apps.
>
> Each block creates interfaces to control data members, by defining ‘get’
> and ‘set’ interface to query and update values of block variables.
> Preference files control the state of ControlPort in section [ControlPort] of 
> gnuradio-runtime.conf.
>
> ControlPort comes with a generic utility to allow you to see all interfaces 
> of a flowgraph:
>
> * gr-ctrlport-monitor  -p 
>
> Within a flowgraph, one can also use ControlPort probes to pass vectors of 
> data to a ControlPort client, including complex IQ data. One useful probe 
> calculates the power spectral density of a block output for remote display.
>
> 

Re: [Discuss-gnuradio] tx_tagged samples hold off the tx stream?

[Josh Blum]

On 07/01/2013 08:53 PM, Gong Zhang wrote:
> Hi,
> Would a sample with tx_tag time in near future hold off the tx stream
> until it is sent?

The tx stream will backup in the fpga and in the host until the time
specified.

-josh

> Thanks.
> 
> ___
> 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] Fwd: Problem in uhd_fft

[Josh Blum]

On 06/29/2013 09:14 AM, Karan Talasila wrote:
> -- Forwarded message --
> From: Karan Talasila 
> Date: Sat, Jun 29, 2013 at 6:44 PM
> Subject: Re: [Discuss-gnuradio] Problem in uhd_fft
> To: "j...@joshknows.com" 
> 
> 
> Hi Josh,
> I am using USRP 1.   I am using a sma-bulkhead cable from Tx_A
> of basic tx daughter board and similarly a sma-bulkhead cable from Rx_A
> terminal of the Basic Rx daughter board. and then i am connecting a sma-sma
> cable from usrp transmitter to a coupler on powerline cable. Similarly I am
> connecting a sma-sma cable from usrp receiver to another coupler on the
> powerline cable.
> 
> so in all I am using 2 usrp 1, 2 sma-sma cables, 2 sma-bulkhead cable and
> two couplers. Please let me know if i am not clear with the description.
> Thank you.
> 

Seems to work OK for me. I used a single USRP1, BasicRX, BasicTX. RXA is
connected to TXA and RXB is connected to TXB. Attached is a GRC flow
graph. Hope that helps.

-josh

> 
> On Sat, Jun 29, 2013 at 11:24 AM, Josh Blum  wrote:
> 
>>
>>
>> On 06/27/2013 09:44 AM, Karan Talasila wrote:
>>> Hi,
>>>   I am using a basic tx and basic rx daughterboard for transmission
>> and
>>> reception. The spec says basic tx and basic rx run from 0 to 250 MHz. But
>>> when i run transmitter and check the uhd_fft at receiver, after 32 Mhz,
>>> there is no signal. If i set the transmitter frequency in my flowgraph as
>>> 33 MHz, I don't get a signal at 33 Mhz, But when i enter frequency as
>>> -31Mhz in the uhd_fft i get a received signal on my fft. why does this
>>> happen? If it's in the range of daughter board it should be receiving it
>> at
>>> that particular frequency right.
>>>
>>>
>>
>> Can you tell me more about the cabling setup? Which ports of the Basic
>> TX and RX are you using, and how are they connected via SMA cable?
>>
>> -josh
>>
>>>
>>> ___
>>> 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
> 


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