Re: [Discuss-gnuradio] Handling custom blocks in GRC

[Moritz Luca Schmid]

Hey Vipin,

here is some information to hier blocks 
 
from the GNU Radio wiki.


If your structure of A_Func is that simple, I think its the best way to 
write the hier block by hand.


When you implement B_Func and C_Func in gr blocks, you have to change 
your A_Func code anyway because you call instances of classes instead of 
functions.


Don't worry about modifying the flow graph. There are multiple methods 
next to connect() (like wait(), unlock(), ..). It is no problem to do 
flow graph controlling inside an if statement. You can read more about 
controlling flow graphs here 
.



If any questions while creating the hier block occur, just ask.


Best regards

Luca


On 24.05.2017 09:06, Vipin Sharma wrote:

Thanks Luca.

I may need a pointer to creating hierarchical python blocks using 
gr_modtool.


My application's A_Func is mostly a control flow logic which simply 
calls the appropriate B_Func or C_Func depending on certain 
conditions. The other job of the A_Func is to pass along the input 
data stream to these sub functions. This, A_Func, of course is very 
easy to code in Matlab. I was trying to find an automated way to 
capture the Matlab control flow logic in GRC. It looks like I have two 
options (both manual):
1) Mimic Matlab's A_Func in Python (hierarchical block). I hope this 
way of doing things still gives me the ability to probe waveforms at 
the output of B_Func for example.
2) Mimic Matlab's A_Func in GRC GUI using the in built basic blocks. 
Not sure how I will code if/else controls in GRC GUI though. Any 
pointers appreciated.

3) Any other idea?

Vipin


On Tue, May 23, 2017 at 11:51 PM Moritz Luca Schmid 
mailto:luca.moritz.sch...@gmail.com>> 
wrote:


Hi Vipin,


The question I have is this: A_Func calls B_Func and C_Func. I
don’t think I can instantiate the three custom blocks directly in
one GRC flow-graph. What will happen to the function call made in
A_Func for B_Func when A_Func custom block is kicked off for
execution by the GRC scheduler? Is there any way in GRC to define
hierarchical custom blocks?


There are hierarchical blocks in GNU Radio, but only for python.
If your A_Func logic is relatively straight forward calling the
other functions, you can try create a python hier block (you can
do this with gr_modtool as well). But if the function calls don't
relate to the data flow, it makes no sense to create different
blocks for each function in my opinion. Remember that a GR block
should fulfill one logical signal processing step. If your
functions separately don't do that, defining multiple methods in
your class of the block is better way to do it.


One way to solve this issue is the have Matlab Coder dump all
code in one C++ file and then simply create one giant custom
block to instantiate in GRC gui. Problem is that I won’t be able
to debug in GRC gui very well (granularity of probe points would
be severally limited).


Anyway, I think it depends on the structure and purpose of your
different functions. Are they each executing a signal processing
step themselves or is only the ensemble of the three functions one
logical signal processing. In the latter case I would implement
the three functions in one block.


Best
Luca



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

Re: [Discuss-gnuradio] Handling custom blocks in GRC

[Vipin Sharma]

Cool, thanks! Will try that out soon.

On Wed, May 24, 2017 at 12:34 AM Moritz Luca Schmid <
luca.moritz.sch...@gmail.com> wrote:

> Hey Vipin,
>
> here is some information to hier blocks
> 
> from the GNU Radio wiki.
>
> If your structure of A_Func is that simple, I think its the best way to
> write the hier block by hand.
>
> When you implement B_Func and C_Func in gr blocks, you have to change your
> A_Func code anyway because you call instances of classes instead of
> functions.
>
> Don't worry about modifying the flow graph. There are multiple methods
> next to connect() (like wait(), unlock(), ..). It is no problem to do flow
> graph controlling inside an if statement. You can read more about
> controlling flow graphs here
> 
> .
>
>
> If any questions while creating the hier block occur, just ask.
>
>
> Best regards
>
> Luca
>
> On 24.05.2017 09:06, Vipin Sharma wrote:
>
> Thanks Luca.
>
> I may need a pointer to creating hierarchical python blocks using
> gr_modtool.
>
> My application's A_Func is mostly a control flow logic which simply calls
> the appropriate B_Func or C_Func depending on certain conditions. The other
> job of the A_Func is to pass along the input data stream to these sub
> functions. This, A_Func, of course is very easy to code in Matlab. I was
> trying to find an automated way to capture the Matlab control flow logic in
> GRC. It looks like I have two options (both manual):
> 1) Mimic Matlab's A_Func in Python (hierarchical block). I hope this way
> of doing things still gives me the ability to probe waveforms at the output
> of B_Func for example.
> 2) Mimic Matlab's A_Func in GRC GUI using the in built basic blocks. Not
> sure how I will code if/else controls in GRC GUI though. Any pointers
> appreciated.
> 3) Any other idea?
>
> Vipin
>
>
> On Tue, May 23, 2017 at 11:51 PM Moritz Luca Schmid <
> luca.moritz.sch...@gmail.com> wrote:
>
>> Hi Vipin,
>>
>> The question I have is this: A_Func calls B_Func and C_Func. I don’t
>> think I can instantiate the three custom blocks directly in one GRC
>> flow-graph. What will happen to the function call made in A_Func for B_Func
>> when A_Func custom block is kicked off for execution by the GRC scheduler?
>> Is there any way in GRC to define hierarchical custom blocks?
>>
>> There are hierarchical blocks in GNU Radio, but only for python. If your
>> A_Func logic is relatively straight forward calling the other functions,
>> you can try create a python hier block (you can do this with gr_modtool as
>> well). But if the function calls don't relate to the data flow, it makes no
>> sense to create different blocks for each function in my opinion. Remember
>> that a GR block should fulfill one logical signal processing step. If your
>> functions separately don't do that, defining multiple methods in your class
>> of the block is better way to do it.
>>
>> One way to solve this issue is the have Matlab Coder dump all code in one
>> C++ file and then simply create one giant custom block to instantiate in
>> GRC gui. Problem is that I won’t be able to debug in GRC gui very well
>> (granularity of probe points would be severally limited).
>>
>> Anyway, I think it depends on the structure and purpose of your different
>> functions. Are they each executing a signal processing step themselves or
>> is only the ensemble of the three functions one logical signal processing.
>> In the latter case I would implement the three functions in one block.
>>
>>
>> Best
>> Luca
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GSL Gnu Scientific Library 2.3

[lists]

Anyone successfully running gnuradio with g‎sl gnu scientific library 2.3 
installed. Success means passing all the "polar" tests. 


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

Re: [Discuss-gnuradio] GSL Gnu Scientific Library 2.3

[Marcus Müller]

Still using an older GSL myself, but what does `ctest -VV -R polar` in
the build directory give you in detailed problems?

Best regards,

Marcus


On 24.05.2017 10:18, li...@lazygranch.com wrote:
> Anyone successfully running gnuradio with g‎sl gnu scientific library 2.3 
> installed. Success means passing all the "polar" tests. 
>
>
> ___
> 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] GSL Gnu Scientific Library 2.3

[li...@lazygranch.com]

Here are the results:

ctest -VV -R polar
UpdateCTestConfiguration  from 
:/usr/local/src/gnuradio_test/gnuradio/build/DartConfiguration.tcl
UpdateCTestConfiguration  from 
:/usr/local/src/gnuradio_test/gnuradio/build/DartConfiguration.tcl
Test project /usr/local/src/gnuradio_test/gnuradio/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 86
Start 86: qa_polar_encoder_systematic

86: Test command: /usr/bin/sh 
"/usr/local/src/gnuradio_test/gnuradio/build/gr-fec/python/fec/qa_polar_encoder_systematic_test.sh"
86: Test timeout computed to be: 9.99988e+06
86: Traceback (most recent call last):  

   
86:   File 
"/usr/local/src/gnuradio_test/gnuradio/gr-fec/python/fec/qa_polar_encoder_systematic.py",
 line 23, in   
86: from gnuradio import gr, gr_unittest, blocks

   
86:   File 
"/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/python/gnuradio/gr/__init__.py",
 line 41, in
86: from runtime_swig import *  

   
86: ImportError: No module named runtime_swig   

   
1/5 Test #86: qa_polar_encoder_systematic ..***Failed0.05 sec   

   
test 89 

   
Start 89: qa_polar_encoder  

   


   
89: Test command: /usr/bin/sh 
"/usr/local/src/gnuradio_test/gnuradio/build/gr-fec/python/fec/qa_polar_encoder_test.sh"
 
89: Test timeout computed to be: 9.99988e+06

   
89: Traceback (most recent call last):  

   
89:   File 
"/usr/local/src/gnuradio_test/gnuradio/gr-fec/python/fec/qa_polar_encoder.py", 
line 23, in 
 
89: from gnuradio import gr, gr_unittest, blocks

   
89:   File 
"/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/python/gnuradio/gr/__init__.py",
 line 41, in
89: from runtime_swig import *  

   
89: ImportError: No module named runtime_swig   

   
2/5 Test #89: qa_polar_encoder .***Failed0.02 sec
test 91
Start 91: qa_polar_decoder_sc

91: Test command: /usr/bin/sh 
"/usr/local/src/gnuradio_test/gnuradio/build/gr-fec/python/fec/qa_polar_decoder_sc_test.sh"
91: Test timeout computed to be: 9.99988e+06
91: Traceback (most recent call last):
91:   File 
"/usr/local/src/gnuradio_test/gnuradio/gr-fec/python/fec/qa_polar_decoder_sc.py",
 line 23, in 
91: from gnuradio import gr, gr_unittest, blocks
91:   File 
"/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/python/gnuradio/gr/__init__.py",
 line 41, in 
91: from runtime_swig import *
91: ImportError: No module named runtime_swig
3/5 Test #91: qa_polar_decoder_sc ..***Failed0.03 sec
test 92
Start 92: qa_polar_decoder_sc_list

92: Test command: /usr/bin/sh 
"/usr/local/src/gnuradio_test/gnuradio/build/gr-fec/python/fec/qa_polar_decoder_sc_list_test.sh"
92: Test timeout computed to be: 9.99988e+06
92: Traceback (most recent call last):
92:   File 
"/usr/local/src/gnuradio_test/gnuradio/gr-fec/python/fec/qa_polar_d

Re: [Discuss-gnuradio] GSL Gnu Scientific Library 2.3

[Michael Dickens]

All of the polar tests work for me on Mac OS X. No reason they shouldn't
work on other OSs.

Your "ctest" below indicates that the GrTest setup for those tests isn't
correct.  "make test" does not always work without GR already being
installed into the $PREFIX, so I generally recommend doing "sudo make
install" before trying testing to make sure the correct libraries /
scripts are installed. It's especially problematic on Mac OS X; a little
less so on Linux because the dynamic linker handled finding libraries
differently.

One way to verify that all -could- work if the GrTest setup were correct
is to edit the test shell script
"/usr/local/src/gnuradio_test/gnuradio/build/gr-fec/python/fec/qa_polar_encoder_systematic_test.sh"
and make sure the settings for PYTHONPATH and LD_LIBRARY_PATH contain
the paths into the build space needed to find all of the various
libraries and scripts.

That, or just do "sudo make install" then "make test"; you can always
"sudo make uninstall" after testing ...

Hope this helps! - MLD

On Wed, May 24, 2017, at 04:58 AM, li...@lazygranch.com wrote:
> Here are the results:
> 
> ctest -VV -R polar
> UpdateCTestConfiguration  from
> :/usr/local/src/gnuradio_test/gnuradio/build/DartConfiguration.tcl
> UpdateCTestConfiguration  from
> :/usr/local/src/gnuradio_test/gnuradio/build/DartConfiguration.tcl
> Test project /usr/local/src/gnuradio_test/gnuradio/build
> Constructing a list of tests
> Done constructing a list of tests
> Checking test dependency graph...
> Checking test dependency graph end
> test 86
> Start 86: qa_polar_encoder_systematic
> 
> 86: Test command: /usr/bin/sh
> "/usr/local/src/gnuradio_test/gnuradio/build/gr-fec/python/fec/qa_polar_encoder_systematic_test.sh"
> 86: Test timeout computed to be: 9.99988e+06
> 86: Traceback (most recent call last):
> 86:   File
> "/usr/local/src/gnuradio_test/gnuradio/gr-fec/python/fec/qa_polar_encoder_systematic.py",
> line 23, in   
> 86: from gnuradio import gr, gr_unittest, blocks  
> 86:   File
> "/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/python/gnuradio/gr/__init__.py",
> line 41, in   
> 86: from runtime_swig import *
> 86: ImportError: No module named runtime_swig 
> 1/5 Test #86: qa_polar_encoder_systematic ..***Failed0.05 sec 
> test 89   
> Start 89: qa_polar_encoder

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

Re: [Discuss-gnuradio] GSL Gnu Scientific Library 2.3

[lists]

I'm not sure I follow you here on the environment variables. They have to be 
proper for both normal and tests operation. 

Regarding sudo, when I am working in /usr/local, I just do su and be done with 
it.

  Original Message  
From: Michael Dickens
Sent: Wednesday, May 24, 2017 6:13 AM
To: li...@lazygranch.com; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GSL Gnu Scientific Library 2.3

All of the polar tests work for me on Mac OS X. No reason they shouldn't
work on other OSs.

Your "ctest" below indicates that the GrTest setup for those tests isn't
correct. "make test" does not always work without GR already being
installed into the $PREFIX, so I generally recommend doing "sudo make
install" before trying testing to make sure the correct libraries /
scripts are installed. It's especially problematic on Mac OS X; a little
less so on Linux because the dynamic linker handled finding libraries
differently.

One way to verify that all -could- work if the GrTest setup were correct
is to edit the test shell script
"/usr/local/src/gnuradio_test/gnuradio/build/gr-fec/python/fec/qa_polar_encoder_systematic_test.sh"
and make sure the settings for PYTHONPATH and LD_LIBRARY_PATH contain
the paths into the build space needed to find all of the various
libraries and scripts.

That, or just do "sudo make install" then "make test"; you can always
"sudo make uninstall" after testing ...

Hope this helps! - MLD

On Wed, May 24, 2017, at 04:58 AM, li...@lazygranch.com wrote:
> Here are the results:
> 
> ctest -VV -R polar
> UpdateCTestConfiguration from
> :/usr/local/src/gnuradio_test/gnuradio/build/DartConfiguration.tcl
> UpdateCTestConfiguration from
> :/usr/local/src/gnuradio_test/gnuradio/build/DartConfiguration.tcl
> Test project /usr/local/src/gnuradio_test/gnuradio/build
> Constructing a list of tests
> Done constructing a list of tests
> Checking test dependency graph...
> Checking test dependency graph end
> test 86
> Start 86: qa_polar_encoder_systematic
> 
> 86: Test command: /usr/bin/sh
> "/usr/local/src/gnuradio_test/gnuradio/build/gr-fec/python/fec/qa_polar_encoder_systematic_test.sh"
> 86: Test timeout computed to be: 9.99988e+06
> 86: Traceback (most recent call last): 
> 86: File
> "/usr/local/src/gnuradio_test/gnuradio/gr-fec/python/fec/qa_polar_encoder_systematic.py",
> line 23, in  
> 86: from gnuradio import gr, gr_unittest, blocks 
> 86: File
> "/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/python/gnuradio/gr/__init__.py",
> line 41, in  
> 86: from runtime_swig import * 
> 86: ImportError: No module named runtime_swig 
> 1/5 Test #86: qa_polar_encoder_systematic ..***Failed 0.05 sec 
> test 89 
> Start 89: qa_polar_encoder 

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

Re: [Discuss-gnuradio] GSL Gnu Scientific Library 2.3

[Michael Dickens]

1) You should do "su" or "sudo" as you see fit. Either way works.

2) The way CMake does testing is that it creates a shell script, which
sets environment variables for just whatever is being executed for that
specific test. These variables are configured in the GR build scripts
via GrTest & variables it makes use of; they are supposed to point to
the internal GR build where libraries ands scripts are located, so that
those are used instead of any already-installed ones. Thus one can edit
the test shell script & tweak just those environment variables to change
what's going on with any specific test, without CMake complaining.

As an example, when I build GR & it's not installed then "ctest -V -R
qa_polar_encoder_systematic" fails for me with the error (I've replaced
the /path/to/ with just "" since it's easier to read & is more
generic):
{{{
97: ImportError: dlopen(/build/gr-blocks/swig/_blocks_swig0.so, 2):
Library not loaded: /opt/local/lib/libgnuradio-blocks.3.7.11.dylib
97:   Referenced from: /build/gr-blocks/swig/_blocks_swig0.so
97:   Reason: image not found
}}}
which indicates that the GrTest configuration for that test is missing
"gr-blocks" (or whatever it is called internal to the GR build) ...
meaning the path to the library libgnuradio-blocks.

So, if I edit the shell script
"/build/gr-fec/python/fec/qa_polar_encoder_systematic_test.sh" &
augment the LD*_LIBRARY_PATH to include "/build/gr-blocks/lib", then
the ctest command works.

3) In your case, it looks like the initial "from gnuradio import gr" is
failing, but we don't know why.

The easiest way to find out is to edit the file (in your case)
"/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/python/gnuradio/gr/__init__.py"
such that the obvious section reads:
{{{
if _swig_python_version_info >= (2, 7, 0):
def swig_import_helper():
import importlib
pkg = __name__.rpartition('.')[0]
mname = '.'.join((pkg, '_runtime_swig')).lstrip('.')
return importlib.import_module(mname)
_runtime_swig = swig_import_helper()
del swig_import_helper
}}}
Then, try the "ctest ..." command again & it should print the actual
import error ... probably some dependent library is missing or some
symbol isn't defined.

I hope this makes sense. Ask more if not. - MLD

On Wed, May 24, 2017, at 09:26 AM, li...@lazygranch.com wrote:
> I'm not sure I follow you here on the environment variables. They have to
> be proper for both normal and tests operation. 
> 
> Regarding sudo, when I am working in /usr/local, I just do su and be done
> with it.

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

Re: [Discuss-gnuradio] GSL Gnu Scientific Library 2.3

[Michael Dickens]

Sorry; wrong file. Should have been (I think)
"/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/swig/runtime_swig.py".

On Wed, May 24, 2017, at 09:53 AM, Michael Dickens wrote:
> The easiest way to find out is to edit the file (in your case)
> "/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/python/gnuradio/gr/__init__.py"

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

Re: [Discuss-gnuradio] GSL Gnu Scientific Library 2.3

[Johannes Demel]

Hi!

as far as I can tell, all tests fail because they fail with
'ImportError: No module named runtime_swig'

This is most probably neither related to GSL nor polar QA tests. Did you 
try a minimal example? Did you install some version of GR? Does the 
failing line 'from gnuradio import gr, gr_unittest, blocks' work if you 
execute it in python directly?


Cheers
Johannes


86: Traceback (most recent call last):
86: File


"/usr/local/src/gnuradio_test/gnuradio/gr-fec/python/fec/qa_polar_encoder_systematic.py",

line 23, in 
86: from gnuradio import gr, gr_unittest, blocks
86: File


"/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/python/gnuradio/gr/__init__.py",

line 41, in 
86: from runtime_swig import *
86: ImportError: No module named runtime_swig




On 24.05.2017 15:26, li...@lazygranch.com wrote:

I'm not sure I follow you here on the environment variables. They have to be 
proper for both normal and tests operation.

Regarding sudo, when I am working in /usr/local, I just do su and be done with 
it.

  Original Message
From: Michael Dickens
Sent: Wednesday, May 24, 2017 6:13 AM
To: li...@lazygranch.com; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GSL Gnu Scientific Library 2.3

All of the polar tests work for me on Mac OS X. No reason they shouldn't
work on other OSs.

Your "ctest" below indicates that the GrTest setup for those tests isn't
correct. "make test" does not always work without GR already being
installed into the $PREFIX, so I generally recommend doing "sudo make
install" before trying testing to make sure the correct libraries /
scripts are installed. It's especially problematic on Mac OS X; a little
less so on Linux because the dynamic linker handled finding libraries
differently.

One way to verify that all -could- work if the GrTest setup were correct
is to edit the test shell script
"/usr/local/src/gnuradio_test/gnuradio/build/gr-fec/python/fec/qa_polar_encoder_systematic_test.sh"
and make sure the settings for PYTHONPATH and LD_LIBRARY_PATH contain
the paths into the build space needed to find all of the various
libraries and scripts.

That, or just do "sudo make install" then "make test"; you can always
"sudo make uninstall" after testing ...

Hope this helps! - MLD

On Wed, May 24, 2017, at 04:58 AM, li...@lazygranch.com wrote:

Here are the results:

ctest -VV -R polar
UpdateCTestConfiguration from
:/usr/local/src/gnuradio_test/gnuradio/build/DartConfiguration.tcl
UpdateCTestConfiguration from
:/usr/local/src/gnuradio_test/gnuradio/build/DartConfiguration.tcl
Test project /usr/local/src/gnuradio_test/gnuradio/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 86
Start 86: qa_polar_encoder_systematic

86: Test command: /usr/bin/sh
"/usr/local/src/gnuradio_test/gnuradio/build/gr-fec/python/fec/qa_polar_encoder_systematic_test.sh"
86: Test timeout computed to be: 9.99988e+06
86: Traceback (most recent call last):
86: File
"/usr/local/src/gnuradio_test/gnuradio/gr-fec/python/fec/qa_polar_encoder_systematic.py",
line 23, in 
86: from gnuradio import gr, gr_unittest, blocks
86: File
"/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/python/gnuradio/gr/__init__.py",
line 41, in 
86: from runtime_swig import *
86: ImportError: No module named runtime_swig
1/5 Test #86: qa_polar_encoder_systematic ..***Failed 0.05 sec
test 89
Start 89: qa_polar_encoder


___
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] GSL Gnu Scientific Library 2.3

[lists]

Now I understand the environment variable issue. Would it make more sense just 
to do a "make install" then see what fails on "make test"? Or will make test 
always use shall we say a custom environment?

‎The rest of the suggestions I will need to chew on later when on the PC.

  Original Message  
From: Michael Dickens
Sent: Wednesday, May 24, 2017 6:53 AM
To: li...@lazygranch.com; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GSL Gnu Scientific Library 2.3

1) You should do "su" or "sudo" as you see fit. Either way works.

2) The way CMake does testing is that it creates a shell script, which
sets environment variables for just whatever is being executed for that
specific test. These variables are configured in the GR build scripts
via GrTest & variables it makes use of; they are supposed to point to
the internal GR build where libraries ands scripts are located, so that
those are used instead of any already-installed ones. Thus one can edit
the test shell script & tweak just those environment variables to change
what's going on with any specific test, without CMake complaining.

As an example, when I build GR & it's not installed then "ctest -V -R
qa_polar_encoder_systematic" fails for me with the error (I've replaced
the /path/to/ with just "" since it's easier to read & is more
generic):
{{{
97: ImportError: dlopen(/build/gr-blocks/swig/_blocks_swig0.so, 2):
Library not loaded: /opt/local/lib/libgnuradio-blocks.3.7.11.dylib
97: Referenced from: /build/gr-blocks/swig/_blocks_swig0.so
97: Reason: image not found
}}}
which indicates that the GrTest configuration for that test is missing
"gr-blocks" (or whatever it is called internal to the GR build) ...
meaning the path to the library libgnuradio-blocks.

So, if I edit the shell script
"/build/gr-fec/python/fec/qa_polar_encoder_systematic_test.sh" &
augment the LD*_LIBRARY_PATH to include "/build/gr-blocks/lib", then
the ctest command works.

3) In your case, it looks like the initial "from gnuradio import gr" is
failing, but we don't know why.

The easiest way to find out is to edit the file (in your case)
"/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/python/gnuradio/gr/__init__.py"
such that the obvious section reads:
{{{
if _swig_python_version_info >= (2, 7, 0):
def swig_import_helper():
import importlib
pkg = __name__.rpartition('.')[0]
mname = '.'.join((pkg, '_runtime_swig')).lstrip('.')
return importlib.import_module(mname)
_runtime_swig = swig_import_helper()
del swig_import_helper
}}}
Then, try the "ctest ..." command again & it should print the actual
import error ... probably some dependent library is missing or some
symbol isn't defined.

I hope this makes sense. Ask more if not. - MLD

On Wed, May 24, 2017, at 09:26 AM, li...@lazygranch.com wrote:
> I'm not sure I follow you here on the environment variables. They have to
> be proper for both normal and tests operation. 
> 
> Regarding sudo, when I am working in /usr/local, I just do su and be done
> with it.

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

Re: [Discuss-gnuradio] GSL Gnu Scientific Library 2.3

[Michael Dickens]

Given my testing locally for that specific QA, I'd advise you to follow
my recommendation (3), since I'm guessing the issue is more to do with
library linkage / missing symbols (probably with respect to libgsl) than
path settings.

Doing "make install" will likely result in the same test failures in the
same way. You can always try "make install" then "ctest ...", and if you
get the same results then do "make uninstall" before doing debugging.

Let us know how it goes when you're on your PC later. - MLD

On Wed, May 24, 2017, at 10:15 AM, li...@lazygranch.com wrote:
> Now I understand the environment variable issue. Would it make more sense
> just to do a "make install" then see what fails on "make test"? Or will
> make test always use shall we say a custom environment?
> 
> ‎The rest of the suggestions I will need to chew on later when on the PC.

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

Re: [Discuss-gnuradio] Mixing multiple streams to audio

[Marcus Müller]

what's the pfb_taps design spec? (i.e. what did you use as argument for
firdes.lowpass()?)

Best regards,

Marcus


On 05/24/2017 04:38 PM, John Ackermann N8UR wrote:
> Here's the whole flowgraph.
>
> Once I get the code functioning, I'm planning to clean this up, maybe
> add a few more channels, and make it easier to customize -- so you'd
> just enter the ch0 carrier frequency and channel spacing, and the rest
> is automatic.
>
> On 05/23/2017 07:24 PM, John Ackermann N8UR wrote:
>> Interesting point, Marcus.  I'll post the complete flowgraph tomorrow
>> when I am at my development machine.  I did revert the audio rate out of
>> the demod to 15ksps and that helped somewhat.  So maybe that can go
>> further.
>> On May 23, 2017, at 7:18 PM, "Marcus Müller" > > wrote:
>>
>> Hi John,
>>
>> 3 to 5 seconds doesn't sound all that much considering that
>> you're doing
>> stuff at a nominal 7.5 kS/s – compare [1]; the typical buffer size
>> between two blocks is 8 kB, and with floats (i.e. 32 b = 4 B),
>> that's
>> 2000 S, and at 7.5 kS/s, that's 2/7.5 s = 0.26667 seconds for the
>> buffers between NBFM demod and add, and between add and
>> resampler. In
>> fact, NBFM demod internally is a hier block (might have more
>> low-rate
>> buffers); so, that's half a second for these two buffers alone...
>>
>> In your very specific use case, using a higher sampling rate
>> might make
>> the problem more manageable. If you'd share the first half of
>> your flow
>> graph, we could discuss options for that!
>>
>> Best regards,
>>
>> Marcus
>>
>> [1] http://gnuradio.org/blog/buffers
>>
>>
>> On 23.05.2017 22:04, John Ackermann N8UR wrote:
>>
>> Hi Marcus and Kevin, and thanks for the info.
>>
>> I've set all squelch gates off. In that case, I get good audio
>> if "OK
>> to block" in the audio sink is set to "yes" but the latency
>> is awful
>> -- 3 to 5 seconds! If "OK to block" is "no", then I get lots
>> of aU
>> and unusable audio.
>>
>> If setting the squelch gates off means that samples are
>> continuously
>> sent through the adder to the sink, I don't understand why
>> blocking
>> makes the difference, or why the latency builds up so fast.
>> I'd try
>> using 44.1ksps on the sink, but the dropdown doesn't allow that
>> choice.
>>
>> John
>> 
>> On 05/23/2017 02:51 PM, Kevin Reid wrote:
>>
>> On Tue, May 23, 2017 at 11:31 AM, John Ackermann N8UR
>> > > wrote:
>>
>> I'm continuing to work on a multi-channel NBFM receiver
>> using the
>> polyphase filter. I have the basic system working, but am
>> hung up
>> on how to get audio out of the system; most of my attempts
>> end up
>> either with audio underruns, or stalls that result in
>> overruns.
>>
>>
>> You're using only one RF source hardware device, correct?
>>
>> Even then, /some/ amount of overrun/underrun is inevitable
>> because the
>> RF receiver and the audio output are not using the same
>> clock
>> oscillator, so the resampling rate you've implemented is
>> not the
>> resampling rate you would ideally need (which there is no
>> way in GR to
>> actually detect or implement).
>>
>>
>> The relevant portion of the flowgraph is attached. Each
>> channel
>> ends up at a 15ksps rate and is fed into a power squelch,
>> then a
>> mult block that's used to mute or unmute the audio, then
>> NBFM
>> demod. The demodulated outputs are at 7.5ksps (though I
>> get the
>> same results with 15ksps) and the seven channels are added.
>> Then a
>> rational resample to 48ksps, volume control, and audio
>> sink at
>> 48ksps.
>>
>> I've tried the "gate" param of the power squelch block both
>> off and
>> on, and the "OK to block" option of the audio sink in
>> various
>> combinations, but I'm not able to get clean audio.
>>
>>
>> "Gate" should be off. What that option does is drop samples.
>> The problem
>> is that the Add block requires samples from every input to
>> produce an
>> output, so if any one of the inputs drops samples then
>> eventually your
>> flowgraph will not be able to make progress because some
>> buffers are
>> overfull and some are empty.
>>
>> Any flowgraph that has paths that split (here, polyphase
>> channelizer)
>> and rejoin (here, add) MUST have exactly the same
>> input-samples-to-output-samples ratio on all of the paths,
>> 

[Discuss-gnuradio] Correlation Estimator Block

[Mojtaba Mansour Abadi]

Hi Everyone,


I am trying to benefit "Correlation Estimator" block to tag the preamble of
the transmit bit sequence in a QPSK-based system


The modulation is done as:
Data + Preamble -> Constellation Modulator


The way I am doing the demodulation is:
AGC -> FLL Band-Edge -> Correlation Estimator -> Correlation Estimator ->
Polyphase Clock Sync -> CMA Equaliser -> Costas Loop

The hard decoding is done as:
Constellation Decoder -> Differential Decoder -> Map -> Unpacked to Packed

After I execute the flowgraph, for a few seconds everything works fine and
I receive the correct sequences. However, after a while, the received bits
are not correct and their pattern changes periodically.

When I bypass the "Correlation Estimator" block, everything works fine and
I receive the correct data.

I am confused. Is the correlation block suppose to deteriorate the
demodulation performance?

The flowgraph is attached to the email.


-- 
Regards,
Mansour.

https://www.linkedin.com/in/mojtaba-mansour-abadi-4311b451


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

Re: [Discuss-gnuradio] Mixing multiple streams to audio

[John Ackermann N8UR]

pfb_taps is (with some variable names simplified for clarity):

 firdes.low_pass(2.0, oversampled_width, fm_dev*2 ,1000,
  firdes.WIN_HAMMING, 6.76)

where oversampled_width = channel_width * (num_chan + 1)

for channel_width = 15 kHz, fm_dev = 5 kHz, and num_chan = 7.

For what it's worth, lpf_taps (used in the frequency xlating filter) is

 firdes.low_pass(1.0, hardware_rate, oversampled_width /
  2,chan_width, firdes.WIN_HAMMING, 6.76)

where hardware rate = 1 msps.


On 05/24/2017 01:00 PM, Marcus Müller wrote:

what's the pfb_taps design spec? (i.e. what did you use as argument for
firdes.lowpass()?)

Best regards,

Marcus


On 05/24/2017 04:38 PM, John Ackermann N8UR wrote:

Here's the whole flowgraph.

Once I get the code functioning, I'm planning to clean this up, maybe
add a few more channels, and make it easier to customize -- so you'd
just enter the ch0 carrier frequency and channel spacing, and the rest
is automatic.

On 05/23/2017 07:24 PM, John Ackermann N8UR wrote:

Interesting point, Marcus.  I'll post the complete flowgraph tomorrow
when I am at my development machine.  I did revert the audio rate out of
the demod to 15ksps and that helped somewhat.  So maybe that can go
further.
On May 23, 2017, at 7:18 PM, "Marcus Müller" mailto:marcus.muel...@ettus.com>> wrote:

Hi John,

3 to 5 seconds doesn't sound all that much considering that
you're doing
stuff at a nominal 7.5 kS/s – compare [1]; the typical buffer size
between two blocks is 8 kB, and with floats (i.e. 32 b = 4 B),
that's
2000 S, and at 7.5 kS/s, that's 2/7.5 s = 0.26667 seconds for the
buffers between NBFM demod and add, and between add and
resampler. In
fact, NBFM demod internally is a hier block (might have more
low-rate
buffers); so, that's half a second for these two buffers alone...

In your very specific use case, using a higher sampling rate
might make
the problem more manageable. If you'd share the first half of
your flow
graph, we could discuss options for that!

Best regards,

Marcus

[1] http://gnuradio.org/blog/buffers


On 23.05.2017 22:04, John Ackermann N8UR wrote:

Hi Marcus and Kevin, and thanks for the info.

I've set all squelch gates off. In that case, I get good audio
if "OK
to block" in the audio sink is set to "yes" but the latency
is awful
-- 3 to 5 seconds! If "OK to block" is "no", then I get lots
of aU
and unusable audio.

If setting the squelch gates off means that samples are
continuously
sent through the adder to the sink, I don't understand why
blocking
makes the difference, or why the latency builds up so fast.
I'd try
using 44.1ksps on the sink, but the dropdown doesn't allow that
choice.

John

On 05/23/2017 02:51 PM, Kevin Reid wrote:

On Tue, May 23, 2017 at 11:31 AM, John Ackermann N8UR
mailto:j...@febo.com>> wrote:

I'm continuing to work on a multi-channel NBFM receiver
using the
polyphase filter. I have the basic system working, but am
hung up
on how to get audio out of the system; most of my attempts
end up
either with audio underruns, or stalls that result in
overruns.


You're using only one RF source hardware device, correct?

Even then, /some/ amount of overrun/underrun is inevitable
because the
RF receiver and the audio output are not using the same
clock
oscillator, so the resampling rate you've implemented is
not the
resampling rate you would ideally need (which there is no
way in GR to
actually detect or implement).


The relevant portion of the flowgraph is attached. Each
channel
ends up at a 15ksps rate and is fed into a power squelch,
then a
mult block that's used to mute or unmute the audio, then
NBFM
demod. The demodulated outputs are at 7.5ksps (though I
get the
same results with 15ksps) and the seven channels are added.
Then a
rational resample to 48ksps, volume control, and audio
sink at
48ksps.

I've tried the "gate" param of the power squelch block both
off and
on, and the "OK to block" option of the audio sink in
various
combinations, but I'm not able to get clean audio.


"Gate" should be off. What that option does is drop samples.
The problem
is that the Add block requires samples from every input to
produce an
output, so if any one of the inputs drops samples then
eventually your
flowgraph will not be able to make progress because some
buffers are
overfull and some are empty.

Any flowgraph that has paths that s

Re: [Discuss-gnuradio] Custom C++ blocks on E310

[Jessica Iwamoto]

Hi all,

I never found the solution to this problem, but I ended up using a work around 
by writing my custom blocks in Python instead of C++.

Jessica

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+jessica.iwamoto=aero@gnu.org] On Behalf Of 
Jessica Iwamoto
Sent: Monday, May 15, 2017 8:38 AM
To: Ben Hilburn 
Cc: discuss-gnuradio@gnu.org
Subject: [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] Re: [Discuss-gnuradio] 
Custom C++ blocks on E310

Hi Ben,

Here is some of the backtrace from the error. At the top level, the error 
starts in the msg_connect function and it looks like it gets tripped up reading 
something from memory when checking for a valid message port.

#0  0xb635c67c in fetch_add (order=boost::memory_order_relaxed, v=1,
storage=@0x6: )
at /home /prefix 
/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:100
#1  fetch_add (order=boost::memory_order_relaxed, v=1, this=0x6)
at /home /prefix 
/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/atomic_template.hpp:115
#2  pmt::intrusive_ptr_add_ref (p=0x2)
at /home /prefix /src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:69
#3  0xb63e56e4 in intrusive_ptr (rhs=..., this=0xbeffec7c)
at /home /prefix 
/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/smart_ptr/intrusive_ptr.hpp:92
#4  gr::flowgraph::check_valid_port (this=this@entry=0x10c578, e=...)
at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:162
#5  0xb63e95d0 in gr::flowgraph::connect (this=this@entry=0x10c578, src=...,
dst=...)
at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:503
#6  0xb63f4c84 in gr::hier_block2_detail::msg_connect (
this=this@entry=0x10c528, src=..., srcport=..., dst=..., dstport=...)
at /home /prefix 
/src/gnuradio/gnuradio-runtime/lib/hier_block2_detail.cc:198
#7  0xb63f1b14 in gr::hier_block2::msg_connect (this=this@entry=0x0, src=...,
srcport=..., dst=..., dstport=...)
at /home /prefix /src/gnuradio/gnuradio-runtime/lib/hier_block2.cc:104
#8  0xb5cd6958 in _wrap_top_block_sptr_primitive_msg_connect__SWIG_1 (
args=)
at /home 
/prefix_new/src/gnuradio/build-arm/gnuradio-runtime/swig/runtime_swigPYTHON_wrap.cxx:47551

Thanks,
Jessica

From: Ben Hilburn [mailto:bhilb...@gnuradio.org]
Sent: Friday, May 12, 2017 1:35 PM
To: Jessica Iwamoto mailto:jessica.iwam...@aero.org>>
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Custom C++ blocks on E310

Hey Jessica -

The SIGBUS you are receiving indicates that there is likely some funniness 
happening with memory addressing / access somewhere. Especially since your test 
flowgraph is so simple, using GDB to get a backtrace might point you to the 
offending code pretty quickly. For more details on how to do this, check out 
this page on our Wiki: 
https://wiki.gnuradio.org/index.php/TutorialsDebugging#Expert_debugging_tools

Have you tried this already? If so, can you share the backtrace?

Cheers,
Ben



On Thu, May 11, 2017 at 6:15 PM, Jessica Iwamoto 
mailto:jessica.iwam...@aero.org>> wrote:
Hi again,

Attached is the code that I’m using if anyone would like to try to replicate my 
issue. The test_msg_py.py file contains the custom python block code for a 
simple message sink. The test_msg_impl.cc, test_msg_impl.h, and test_msg.h 
files contain the custom C++ code for a message sink. The test.py file contains 
a simple flowgraph that connects a message strobe to my custom message sink 
blocks. When I run test.py with either of the blocks on my desktop, it works 
correctly. However, when I run test.py after cross compiling on the E310, it 
works correctly with the test_msg_py block and produces the following error 
with the test_msg block:
Could not find port: in in:
system
Bus error

Thanks,
Jessica

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+jessica.iwamoto=aero@gnu.org]
 On Behalf Of Jessica Iwamoto
Sent: Wednesday, May 10, 2017 9:53 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Custom C++ blocks on E310

Hi all,

I have built custom C++ blocks that work on my PC, but don’t work when cross 
compiled for the E310. Specifically, I am trying to build a custom C++ block 
with a message port and cross compile it for the E310. I am using version 
3.7.12 of GNU radio and the latest version of the SDK/toolchain for the E310. I 
have built a simple message sink block with just a message input port and put 
it in a flowgraph with a message strobe. My code runs correctly on my PC but 
when I run it on the E310, I get the error:
Could not find port: msg in:
system
Bus error

I am able to create custom python blocks with message ports and run them on the 
E310 and my PC with no issues. Additionally, I am unable to create custom C++ 
blocks with normal input and output streams 

Re: [Discuss-gnuradio] Custom C++ blocks on E310

[Marcus Müller]

Hi Jessica,

that's really interesting!

It means that the problem only happens when you use your compiler to
build your C++ blocks, but not when only using the GNU Radio that's
already part of your image. Not quite sure what that entails; maybe it
means that openembedded builds broken SDKs... That shouldn't happen. The
other thing I could think of would be a slight misconfiguration of the
compiler (or the linker). Maybe Philip has an idea!

Best regards,

Marcus



On 24.05.2017 20:51, Jessica Iwamoto wrote:
>
> Hi all,
>
>  
>
> I never found the solution to this problem, but I ended up using a
> work around by writing my custom blocks in Python instead of C++.
>
>  
>
> Jessica
>
>  
>
> *From:*Discuss-gnuradio
> [mailto:discuss-gnuradio-bounces+jessica.iwamoto=aero@gnu.org] *On
> Behalf Of *Jessica Iwamoto
> *Sent:* Monday, May 15, 2017 8:38 AM
> *To:* Ben Hilburn 
> *Cc:* discuss-gnuradio@gnu.org
> *Subject:* [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] Re:
> [Discuss-gnuradio] Custom C++ blocks on E310
>
>  
>
> Hi Ben,
>
>  
>
> Here is some of the backtrace from the error. At the top level, the
> error starts in the msg_connect function and it looks like it gets
> tripped up reading something from memory when checking for a valid
> message port.
>
>  
>
> #0  0xb635c67c in fetch_add (order=boost::memory_order_relaxed, v=1,
>
> storage=@0x6: )
>
> at /home /prefix
> /sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:100
>
> #1  fetch_add (order=boost::memory_order_relaxed, v=1, this=0x6)
>
> at /home /prefix
> /sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/atomic_template.hpp:115
>
> #2  pmt::intrusive_ptr_add_ref (p=0x2)
>
> at /home /prefix /src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:69
>
> #3  0xb63e56e4 in intrusive_ptr (rhs=..., this=0xbeffec7c)
>
> at /home /prefix
> /sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/smart_ptr/intrusive_ptr.hpp:92
>
> #4  gr::flowgraph::check_valid_port (this=this@entry=0x10c578, e=...)
>
> at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:162
>
> #5  0xb63e95d0 in gr::flowgraph::connect (this=this@entry=0x10c578,
> src=...,
>
> dst=...)
>
> at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:503
>
> #6  0xb63f4c84 in gr::hier_block2_detail::msg_connect (
>
> this=this@entry=0x10c528, src=..., srcport=..., dst=..., dstport=...)
>
> at /home /prefix
> /src/gnuradio/gnuradio-runtime/lib/hier_block2_detail.cc:198
>
> #7  0xb63f1b14 in gr::hier_block2::msg_connect (this=this@entry=0x0,
> src=...,
>
> srcport=..., dst=..., dstport=...)
>
> at /home /prefix /src/gnuradio/gnuradio-runtime/lib/hier_block2.cc:104
>
> #8  0xb5cd6958 in _wrap_top_block_sptr_primitive_msg_connect__SWIG_1 (
>
> args=)
>
> at /home
> /prefix_new/src/gnuradio/build-arm/gnuradio-runtime/swig/runtime_swigPYTHON_wrap.cxx:47551
>
>  
>
> Thanks,
>
> Jessica
>
>  
>
> *From:*Ben Hilburn [mailto:bhilb...@gnuradio.org]
> *Sent:* Friday, May 12, 2017 1:35 PM
> *To:* Jessica Iwamoto  >
> *Cc:* discuss-gnuradio@gnu.org 
> *Subject:* Re: [Discuss-gnuradio] Custom C++ blocks on E310
>
>  
>
> Hey Jessica -
>
>  
>
> The SIGBUS you are receiving indicates that there is likely some
> funniness happening with memory addressing / access somewhere.
> Especially since your test flowgraph is so simple, using GDB to get a
> backtrace might point you to the offending code pretty quickly. For
> more details on how to do this, check out this page on our
> Wiki: 
> https://wiki.gnuradio.org/index.php/TutorialsDebugging#Expert_debugging_tools
>
>  
>
> Have you tried this already? If so, can you share the backtrace?
>
>  
>
> Cheers,
>
> Ben
>
>  
>
>  
>
>  
>
> On Thu, May 11, 2017 at 6:15 PM, Jessica Iwamoto
> mailto:jessica.iwam...@aero.org>> wrote:
>
> Hi again,
>
>  
>
> Attached is the code that I’m using if anyone would like to try to
> replicate my issue. The test_msg_py.py file contains the custom
> python block code for a simple message sink. The test_msg_impl.cc,
> test_msg_impl.h, and test_msg.h files contain the custom C++ code
> for a message sink. The test.py file contains a simple flowgraph
> that connects a message strobe to my custom message sink blocks.
> When I run test.py with either of the blocks on my desktop, it
> works correctly. However, when I run test.py after cross compiling
> on the E310, it works correctly with the test_msg_py block and
> produces the following error with the test_msg block:
>
> Could not find port: in in:
>
> system
>
> Bus error
>
>  
>
> Thanks,
>
> Jessica
>
>  
>
> *From:* Discuss-gnuradio
> [mailto:discuss-gnuradio-bounces+jessica.iwamoto
> =aero@gnu.org
> 

Re: [Discuss-gnuradio] Mixing multiple streams to audio

[Marcus Müller]

Hi John,

more of a note pad than an email:

*PFB*

>  firdes.low_pass(2.0, oversampled_width, fm_dev*2 ,1000,
>   firdes.WIN_HAMMING, 6.76) 
low_pass(double gain, double sampling_freq, double cutoff_freq, double
transition_width, gr::filter::firdes::win_type window, double beta=6.76)

gain = 2
sampling_freq = oversampled_width =15e3*8 = 120e3,
cutoff = fm_dev *2 = 10e3,
transition_width= 1000 = sampling_freq/120

Those are pretty reasonable numbers; if anything, you could try to
slightly relax the transition width; the ratio between sampling rate and
transition width of a FIR typically [1] influences the length, and thus
the delay, of a linear phase filter.

eyeballing, this should be a filter of about 300 taps length

*LPF*

>  firdes.low_pass(1.0, hardware_rate, oversampled_width /
>   2,chan_width, firdes.WIN_HAMMING, 6.76)
transition_width = chan_width = sampling_rate/66.66

this filter should be about half as long as the one above.

*Conclusion*

While these filters aren't the smallest filters in the world, a group
delay of ca 150 and 75 samples shouldn't be the issue here.

Best regards,

Marcus

[1] https://dsp.stackexchange.com/a/31077/13320


On 24.05.2017 20:45, John Ackermann N8UR wrote:
> pfb_taps is (with some variable names simplified for clarity):
>
>  firdes.low_pass(2.0, oversampled_width, fm_dev*2 ,1000,
>   firdes.WIN_HAMMING, 6.76)
>
> where oversampled_width = channel_width * (num_chan + 1)
>
> for channel_width = 15 kHz, fm_dev = 5 kHz, and num_chan = 7.
>
> For what it's worth, lpf_taps (used in the frequency xlating filter) is
>
>  firdes.low_pass(1.0, hardware_rate, oversampled_width /
>   2,chan_width, firdes.WIN_HAMMING, 6.76)
>
> where hardware rate = 1 msps.
>
>
> On 05/24/2017 01:00 PM, Marcus Müller wrote:
>> what's the pfb_taps design spec? (i.e. what did you use as argument for
>> firdes.lowpass()?)
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 05/24/2017 04:38 PM, John Ackermann N8UR wrote:
>>> Here's the whole flowgraph.
>>>
>>> Once I get the code functioning, I'm planning to clean this up, maybe
>>> add a few more channels, and make it easier to customize -- so you'd
>>> just enter the ch0 carrier frequency and channel spacing, and the rest
>>> is automatic.
>>>
>>> On 05/23/2017 07:24 PM, John Ackermann N8UR wrote:
 Interesting point, Marcus.  I'll post the complete flowgraph tomorrow
 when I am at my development machine.  I did revert the audio rate
 out of
 the demod to 15ksps and that helped somewhat.  So maybe that can go
 further.
 On May 23, 2017, at 7:18 PM, "Marcus Müller" >>> > wrote:

 Hi John,

 3 to 5 seconds doesn't sound all that much considering that
 you're doing
 stuff at a nominal 7.5 kS/s – compare [1]; the typical buffer size
 between two blocks is 8 kB, and with floats (i.e. 32 b = 4 B),
 that's
 2000 S, and at 7.5 kS/s, that's 2/7.5 s = 0.26667 seconds for the
 buffers between NBFM demod and add, and between add and
 resampler. In
 fact, NBFM demod internally is a hier block (might have more
 low-rate
 buffers); so, that's half a second for these two buffers alone...

 In your very specific use case, using a higher sampling rate
 might make
 the problem more manageable. If you'd share the first half of
 your flow
 graph, we could discuss options for that!

 Best regards,

 Marcus

 [1] http://gnuradio.org/blog/buffers


 On 23.05.2017 22:04, John Ackermann N8UR wrote:

 Hi Marcus and Kevin, and thanks for the info.

 I've set all squelch gates off. In that case, I get good audio
 if "OK
 to block" in the audio sink is set to "yes" but the latency
 is awful
 -- 3 to 5 seconds! If "OK to block" is "no", then I get lots
 of aU
 and unusable audio.

 If setting the squelch gates off means that samples are
 continuously
 sent through the adder to the sink, I don't understand why
 blocking
 makes the difference, or why the latency builds up so fast.
 I'd try
 using 44.1ksps on the sink, but the dropdown doesn't allow
 that
 choice.

 John
 
 On 05/23/2017 02:51 PM, Kevin Reid wrote:

 On Tue, May 23, 2017 at 11:31 AM, John Ackermann N8UR
 >>> > wrote:

 I'm continuing to work on a multi-channel NBFM receiver
 using the
 polyphase filter. I have the basic system working, but am
 hung up
 on how to get audio out of the system; most of my attempts
 end up
 either with audio underruns, or st

Re: [Discuss-gnuradio] Correlation Estimator Block

[Cinaed Simson]

There's an excellent example using BPSK in


/share/gnuradio/examples/digital/packet/example_corr_est.grc

Also, you should be using a tagged stream and blocking tag propagation
at the Channel Model.

And since there are no taps in the Channel Model, you really don't need
CMA Equalizer, and the Costas Loop - or even the Polyphase Clock Sync.

Keep it simple until you understand how the above example works.

The first thing I would do is loose the Constellation Modulator at the
beginning.

But don't confuse me with someone who knows what they're doing - I'm
still wandering through the forest.

-- Cinaed



On 05/24/2017 10:32 AM, Mojtaba Mansour Abadi wrote:
> Hi Everyone,
> 
> 
> I am trying to benefit "Correlation Estimator" block to tag the preamble
> of the transmit bit sequence in a QPSK-based system
> 
> 
> The modulation is done as:
> Data + Preamble -> Constellation Modulator
> 
> 
> The way I am doing the demodulation is:
> AGC -> FLL Band-Edge -> Correlation Estimator -> Correlation Estimator
> -> Polyphase Clock Sync -> CMA Equaliser -> Costas Loop
> 
> The hard decoding is done as:
> Constellation Decoder -> Differential Decoder -> Map -> Unpacked to Packed
> 
> After I execute the flowgraph, for a few seconds everything works fine
> and I receive the correct sequences. However, after a while, the
> received bits are not correct and their pattern changes periodically.
> 
> When I bypass the "Correlation Estimator" block, everything works fine
> and I receive the correct data.
> 
> I am confused. Is the correlation block suppose to deteriorate the
> demodulation performance?
> 
> The flowgraph is attached to the email.
> 
> 
> -- 
> Regards,
> Mansour.
> 
> https://www.linkedin.com/in/mojtaba-mansour-abadi-4311b451
> 
> 
> ___
> 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] How to write data periodically in file sink

[Deepak Gautam]

Dear paul,luca,


Thank you for the kind response. Yes, i need the high accuracy and i think
i should go with "issue_stream_cmd" method. Before i start working in this
method, my concern is whether i can write the different burst in separate
file. My main conern is written file size. Because i have to record data
for few minutes With my sampling rate of 25msps. I got problem of overflow
when i write in normal hard disk. So i am writing data in RAM disk by which
i dont get overflow. Due to size limitation of the Ram disk, i will not be
able to write all data in one file. If i write in different file, i can
move previous files back to hard disk and proceed. If there is a way of
writing in a file for 3/4 minutes with 25msps without overflow , i dont
need burst reception also. I appreciate your opinion

Best regards,
Deepak




On Sun, May 21, 2017 at 6:24 PM Paul I.  wrote:

> You need to use USRP "issue_stream_cmd" method (mode:
> STREAM_MODE_NUM_SAMPS_AND_DONE). It's allow to receive burst of data by
> USRP timer.
> If you work in GRC:
> 1) Disable streaming autostart for "UHD source"
> 2) Create your own block which will periodically issue stream commands
> (yes, you need to pass USRP pointer to it)
> a) For stream command set "num_samples" =  sample_rate * 1 sec
> b) Read the USRP timer value, add some time offset to it and use this
> value as timestamp for the first stream command
> c) Increment timestamp after every stream command
> ...
> 3) Profit!
>
> 2017-05-20 10:09 GMT+03:00 Gilad Beeri (ApolloShield) <
> gi...@apolloshield.com>:
>
>> If you need accuracy, I think the asynchronous nature of your method
>> might problematic (will appreciate input from GR devs).
>> Maybe try a different approach - write the samples to a memory buffer,
>> then read from the buffer the exact # of samples you want to write to a
>> file.
>>
>> On Fri, May 19, 2017 at 5:02 PM Deepak Gautam  wrote:
>>
>>> Dear luca,
>>>
>>> I had already tried with controlling flow graph dynamically using
>>> start(), stop(), lock(), unlock() function. Here i have the part of code i
>>> had used.
>>>
>>> tb=top_block_cls()
>>> count=1
>>> tb.start()
>>> while (count<5):
>>> time.sleep(1.0)   #data is recorded in the file
>>> tb.lock()
>>> tb.disconnect((tb.uhd_usrp_source_0,0),(tb.blocks_file_sink_0, 0))
>>> #disconnect source and block
>>> tb.blocks_file_sink_0= blocks.file_sink(gr.sizeof_gr_complex*1,
>>> filename,False)  # create new file sink to write
>>> tb.connect((tb.uhd_usrp_source_0,0),(tb.blocks_file_sink_0, 0))
>>>  #connect source with new file
>>> count=count+1
>>> time.sleep(2.0)   #wait
>>> tb.unlock()
>>> tb.stop()
>>>
>>>
>>> This program should write the data for 1 second in the file, wait for 2
>>> second and again write for 1 second to another file and so on for 5 4
>>> times. I expect the total data written in the file to be same. But total
>>> number of samples recorded in the files are different. for my sampling rate
>>> of 25MSps, it should record 25MS per file, but it is around 22Mega sample
>>> with different number of data in different file.  So it is difficult to
>>> reproduce the accurate signal from received data . My application requires
>>> very good phase coherence. So i am wondering whether there is something to
>>> do to solve in this method or i have to think of another idea.
>>>
>>>
>>> Best Regards,
>>> Deepak
>>>
>>>
>>>
>>> On Mon, May 15, 2017 at 9:02 PM Moritz Luca Schmid <
>>> luca.moritz.sch...@gmail.com> wrote:
>>>
 Hey Deepak,

 my first idea is to reconfigure the flowgraph. You could connect and
 disconnect your source for the time, you want to write data in your file
 sink and the time you don't want to.

 You can find infos about the flowgraphs operations here
 .


 Best

 Luca



 On 15.05.2017 13:53, Deepak Gautam wrote:

 Currently i am working in the USRP using GNU Radio for my masters work.
 In my transmitter side, i send data continuously from file source followed
 by UHD Sink at the rate of 25 MSPS. In receiver side, I want to write the
 data in every two/three seconds after receiving from receiver USRP.
 Meaning, write data for 1 sec (25M samples), then dont write for next 2
 second and again write for 1 sec and so on. Is there any suggestion for
 this purpose. I look forward for the resposne


 Best Regards,
 Deepak


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

Re: [Discuss-gnuradio] How to write data periodically in file sink

[Deepak Gautam]

On Thu, May 25, 2017 at 10:34 AM Deepak Gautam  wrote:

> Dear  Gilad, paul,luca
>
>
> Thank you for the kind response. Yes, i need the high accuracy and i think
> i should go with "issue_stream_cmd" method. Before i start working in this
> method, my concern is whether i can write the different burst in separate
> file. My main conern is written file size. Because i have to record data
> for few minutes With my sampling rate of 25msps. I got problem of overflow
> when i write in normal hard disk. So i am writing data in RAM disk by which
> i dont get overflow. Due to size limitation of the Ram disk, i will not be
> able to write all data in one file. If i write in different file, i can
> move previous files back to hard disk and proceed. If there is a way of
> writing in a file for 3/4 minutes with 25msps without overflow , i dont
> need burst reception also. I appreciate your opinion
>
> Best regards,
> Deepak
>
>
>
> On Sun, May 21, 2017 at 6:24 PM Paul I.  wrote:
>
>> You need to use USRP "issue_stream_cmd" method (mode:
>> STREAM_MODE_NUM_SAMPS_AND_DONE). It's allow to receive burst of data by
>> USRP timer.
>> If you work in GRC:
>> 1) Disable streaming autostart for "UHD source"
>> 2) Create your own block which will periodically issue stream commands
>> (yes, you need to pass USRP pointer to it)
>> a) For stream command set "num_samples" =  sample_rate * 1 sec
>> b) Read the USRP timer value, add some time offset to it and use this
>> value as timestamp for the first stream command
>> c) Increment timestamp after every stream command
>> ...
>> 3) Profit!
>>
>> 2017-05-20 10:09 GMT+03:00 Gilad Beeri (ApolloShield) <
>> gi...@apolloshield.com>:
>>
>>> If you need accuracy, I think the asynchronous nature of your method
>>> might problematic (will appreciate input from GR devs).
>>> Maybe try a different approach - write the samples to a memory buffer,
>>> then read from the buffer the exact # of samples you want to write to a
>>> file.
>>>
>>> On Fri, May 19, 2017 at 5:02 PM Deepak Gautam 
>>> wrote:
>>>
 Dear luca,

 I had already tried with controlling flow graph dynamically using
 start(), stop(), lock(), unlock() function. Here i have the part of code i
 had used.

 tb=top_block_cls()
 count=1
 tb.start()
 while (count<5):
 time.sleep(1.0)   #data is recorded in the file
 tb.lock()
 tb.disconnect((tb.uhd_usrp_source_0,0),(tb.blocks_file_sink_0, 0))
   #disconnect source and block
 tb.blocks_file_sink_0= blocks.file_sink(gr.sizeof_gr_complex*1,
 filename,False)  # create new file sink to write
 tb.connect((tb.uhd_usrp_source_0,0),(tb.blocks_file_sink_0, 0))
  #connect source with new file
 count=count+1
 time.sleep(2.0)   #wait
 tb.unlock()
 tb.stop()


 This program should write the data for 1 second in the file, wait for 2
 second and again write for 1 second to another file and so on for 5 4
 times. I expect the total data written in the file to be same. But total
 number of samples recorded in the files are different. for my sampling rate
 of 25MSps, it should record 25MS per file, but it is around 22Mega sample
 with different number of data in different file.  So it is difficult to
 reproduce the accurate signal from received data . My application requires
 very good phase coherence. So i am wondering whether there is something to
 do to solve in this method or i have to think of another idea.


 Best Regards,
 Deepak



 On Mon, May 15, 2017 at 9:02 PM Moritz Luca Schmid <
 luca.moritz.sch...@gmail.com> wrote:

> Hey Deepak,
>
> my first idea is to reconfigure the flowgraph. You could connect and
> disconnect your source for the time, you want to write data in your file
> sink and the time you don't want to.
>
> You can find infos about the flowgraphs operations here
> .
>
>
> Best
>
> Luca
>
>
>
> On 15.05.2017 13:53, Deepak Gautam wrote:
>
> Currently i am working in the USRP using GNU Radio for my masters
> work. In my transmitter side, i send data continuously from file source
> followed by UHD Sink at the rate of 25 MSPS. In receiver side, I want to
> write the data in every two/three seconds after receiving from receiver
> USRP. Meaning, write data for 1 sec (25M samples), then dont write for 
> next
> 2 second and again write for 1 sec and so on. Is there any suggestion for
> this purpose. I look forward for the resposne
>
>
> Best Regards,
> Deepak
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___

Re: [Discuss-gnuradio] Trouble with gnuradio-companion after pybombs installation

[Pavan Yedavalli]

To Kyeong and Cinaed: Thank you for the suggestions.

I am still having a ton of the same issues. What I did was the following:

1) Removed the pybombs and prefix directories to start from scratch. Is
this all I need to do in order to get rid of everything I previously
installed? I have a feeling that maybe there are some lurking old files
that haven't been purged just by removing those directories.

2) Re-installed pybombs with the /usr/local prefix and also additional OOT
modules. Those were successful and now everything is installed in that
directory:

pavan@pavan-ThinkPad-T430:/usr/local/lib/python2.7/dist-packages$ ls
easy-install.pth gnuradio  osmosdr
PyBOMBS-2.3.1a0-py2.7.egg   setuptools.pth  _SoapySDR.so
thrift-0.9.3-py2.7.egg-info  volk_modtool
future-0.16.0-py2.7.egg  grc_gnuradio  pmt
PyYAML-3.12-py2.7-linux-x86_64.egg  SoapySDR.py thrifttutorial

3) However, now when I do gnuradio-companion or sudo gnuradio-companion or
pybombs run gnuradio-companion, it all gives the same 'No module named
main' error, even though main.py exists in gnuradio/grc/. I don't know what
the problem is here. When I check gnuradio-companion --version, it gives
the same error. When I echo the paths you mentioned, they all seem normal:

pavan@pavan-ThinkPad-T430:~$ echo $PYTHONPATH
/usr/local/python:/usr/local/lib/python2.6/site-packages:/usr/local/lib64/python2.6/site-packages:/usr/local/lib/python2.6/dist-packages:/usr/local/lib64/python2.6/dist-packages:/usr/local/lib/python2.7/site-packages:/usr/local/lib64/python2.7/site-packages:/usr/local/lib/python2.7/dist-packages:/usr/local/lib64/python2.7/dist-packages:

pavan@pavan-ThinkPad-T430:~$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

pavan@pavan-ThinkPad-T430:~$ echo $LD_LIBRARY_PATH
/usr/local/lib:/usr/local/lib64/:

pavan@pavan-ThinkPad-T430:~$ echo $C_INCLUDE_PATH (this is empty)

pavan@pavan-ThinkPad-T430:~$ echo $CPLUS_INCLUDE_PATH (this is empty)

At least last time gnuradio-companion seemed to open; now it doesn't work
at all.


4) Though I know this next step is a fruitless endeavor, I gave it a shot
anyway: when I actually run my python file, now it's giving a segfault;
previously it was the "No module named tutorial" error. This probably is
because gnuradio-companion can't even open.

I seemed to have regressed, but I do feel like everything should work
correctly if I was able to clean everything fully and just do these
instructions from scratch (or at the very least get gnuradio-companion
working and get my python flowgraph to start running even slightly again).
I'm not sure this is the right approach though.

Please let me know. Thank you so much again for the help.




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

Re: [Discuss-gnuradio] Trouble with gnuradio-companion after pybombs installation

[Cinaed Simson]

On 05/24/2017 07:29 PM, Pavan Yedavalli wrote:
> To Kyeong and Cinaed: Thank you for the suggestions.
> 
> I am still having a ton of the same issues. What I did was the following:
> 
> 1) Removed the pybombs and prefix directories to start from scratch. Is
> this all I need to do in order to get rid of everything I previously
> installed? 

Yes - it removes everything installed in ~/prefix.

>I have a feeling that maybe there are some lurking old files
> that haven't been purged just by removing those directories.

Now that you're in commonly used directories, it's possible there is old
installation lurking somewhere.

For completeness, check the system installs first

  apt list --installed | grep gnuradio

Shouldn't return anything. If it wasn't a problem before your first
pybombs install, it shouldn't be a problem now.

> 
> 2) Re-installed pybombs with the /usr/local prefix and also additional
> OOT modules. Those were successful and now everything is installed in
> that directory
>
> pavan@pavan-ThinkPad-T430:/usr/local/lib/python2.7/dist-packages$ ls
> easy-install.pth gnuradio  osmosdr 
> PyBOMBS-2.3.1a0-py2.7.egg   setuptools.pth  _SoapySDR.so 
> thrift-0.9.3-py2.7.egg-info  volk_modtool
> future-0.16.0-py2.7.egg  grc_gnuradio  pmt 
> PyYAML-3.12-py2.7-linux-x86_64.egg  SoapySDR.py thrifttutorial
> 

Great!

> 3) However, now when I do gnuradio-companion or sudo gnuradio-companion
> or pybombs run gnuradio-companion, it all gives the same 'No module
> named main' error, even though main.py exists in gnuradio/grc/. I don't
> know what the problem is here. When I check gnuradio-companion
> --version, it gives the same error. When I echo the paths you mentioned,
> they all seem normal:

Type

  which gnuradio-companion

should return

  /usr/local/bin/gnuradio-companion

Check the permissions

  ls -tld /usr/local/bin/gnuradio-companion

It's possible the umask for root is restrictive.

If you get an error, type

  ls -tld /usr/local/bin

> 
> pavan@pavan-ThinkPad-T430:~$ echo $PYTHONPATH
> /usr/local/python:/usr/local/lib/python2.6/site-packages:/usr/local/lib64/python2.6/site-packages:/usr/local/lib/python2.6/dist-packages:/usr/local/lib64/python2.6/dist-packages:/usr/local/lib/python2.7/site-packages:/usr/local/lib64/python2.7/site-packages:/usr/local/lib/python2.7/dist-packages:/usr/local/lib64/python2.7/dist-packag

I would also try putting

   /usr/local/lib/python2.7/dist-packages

at the beginning of your PYTHONPATH.

Or comment out the existing PYTHONPATH in .bashrc file and set it to

   PYTHONPATH=/usr/local/lib/python2.7/dist-package

and source it

   . $HOME/.bashrc

Then check the PYTHONPATH and see what happens when you try to start it
again.

> 
> pavan@pavan-ThinkPad-T430:~$ echo $PATH
> /usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
> 
> pavan@pavan-ThinkPad-T430:~$ echo $LD_LIBRARY_PATH
> /usr/local/lib:/usr/local/lib64/:

Type

  ldconfig -v | grep gnuradio

I'm not sure if gnuradio actually modifies the /etc/ld.so.conf.d files.

If there is output note the version.

> 
> pavan@pavan-ThinkPad-T430:~$ echo $C_INCLUDE_PATH (this is empty)
> 
> pavan@pavan-ThinkPad-T430:~$ echo $CPLUS_INCLUDE_PATH (this is empty)
> 
> At least last time gnuradio-companion seemed to open; now it doesn't
> work at all>
> 
> 4) Though I know this next step is a fruitless endeavor, I gave it a
> shot anyway: when I actually run my python file, now it's giving a
> segfault; previously it was the "No module named tutorial" error. This
> probably is because gnuradio-companion can't even open.
> 
> I seemed to have regressed, but I do feel like everything should work
> correctly if I was able to clean everything fully and just do these
> instructions from scratch (or at the very least get gnuradio-companion
> working and get my python flowgraph to start running even slightly
> again). I'm not sure this is the right approach though.

You're headed in the right direction. Even though you crash and burn,
typically these type of problem are minor. If you re-install you may
just end up reproducing the problem.

> 
> Please let me know. Thank you so much again for the help.
> 
> 
> 
> 
> -- 
> Pavan
> 
> 
> ___
> 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