Re: [Discuss-gnuradio] gnuradio-companion-3.8.0 fails to run

[Barry Jackson]

On 30/10/2019 00:09, Barry Jackson wrote:

On 27/10/2019 11:58, Marcus Müller wrote:

ah! I missed the part where you said you're not used to Python.

In Python, indentation is structure-defining, and  the error message
sadly doesn't really give context, but it looks like the most probable
explanation is that the line you've inserted is not correctly indented.

Make sure you're using the same characters to indent (spaces) and the
same amount of additional spaces to indent the content of the try:-
block.

Best regards,
Marcus



Thanks Marcus,
I did not realize about indentation in python.
I have corrected this by using tabs only as used by similar structures 
in the same file.

On running grc I get:

[baz@jackodesktop gnuradio]$ gnuradio-companion
Traceback (most recent call last):
   File 
"/usr/lib/python3.8/site-packages/gnuradio/grc/gui/Application.py", line 
102, in do_activate

     self.main_window = MainWindow(self, self.platform)
   File 
"/usr/lib/python3.8/site-packages/gnuradio/grc/gui/MainWindow.py", line 
84, in __init__

     generate_modes = platform.get_generate_options()
   File 
"/usr/lib/python3.8/site-packages/gnuradio/grc/core/platform.py", line 
379, in get_generate_options

     for param in self.block_classes['options'].parameters_data:
   File "/usr/lib64/python3.8/collections/__init__.py", line 891, in 
__getitem__
     return self.__missing__(key)    # support subclasses that 
define __missing__
   File "/usr/lib64/python3.8/collections/__init__.py", line 883, in 
__missing__

     raise KeyError(key)
KeyError: 'options'

The patch applying your change is attached.

Regards,
Barry





I have opened an issue on github.
https://github.com/gnuradio/gnuradio/issues/2873

Re: [Discuss-gnuradio] gnuradio-companion-3.8.0 fails to run

[Barry Jackson]

On 27/10/2019 11:58, Marcus Müller wrote:

ah! I missed the part where you said you're not used to Python.

In Python, indentation is structure-defining, and  the error message
sadly doesn't really give context, but it looks like the most probable
explanation is that the line you've inserted is not correctly indented.

Make sure you're using the same characters to indent (spaces) and the
same amount of additional spaces to indent the content of the try:-
block.

Best regards,
Marcus



Thanks Marcus,
I did not realize about indentation in python.
I have corrected this by using tabs only as used by similar structures 
in the same file.

On running grc I get:

[baz@jackodesktop gnuradio]$ gnuradio-companion
Traceback (most recent call last):
  File 
"/usr/lib/python3.8/site-packages/gnuradio/grc/gui/Application.py", line 
102, in do_activate

self.main_window = MainWindow(self, self.platform)
  File 
"/usr/lib/python3.8/site-packages/gnuradio/grc/gui/MainWindow.py", line 
84, in __init__

generate_modes = platform.get_generate_options()
  File 
"/usr/lib/python3.8/site-packages/gnuradio/grc/core/platform.py", line 
379, in get_generate_options

for param in self.block_classes['options'].parameters_data:
  File "/usr/lib64/python3.8/collections/__init__.py", line 891, in 
__getitem__
return self.__missing__(key)# support subclasses that 
define __missing__
  File "/usr/lib64/python3.8/collections/__init__.py", line 883, in 
__missing__

raise KeyError(key)
KeyError: 'options'

The patch applying your change is attached.

Regards,
Barry



diff -ur gnuradio-3.8.0.0_o/grc/core/platform.py gnuradio-3.8.0.0/grc/core/platform.py
--- gnuradio-3.8.0.0_o/grc/core/platform.py	2019-08-09 22:40:34.0 +0100
+++ gnuradio-3.8.0.0/grc/core/platform.py	2019-10-29 23:00:17.161851477 +
@@ -194,7 +194,10 @@
 
 self._docstring_extractor.finish()
 # self._docstring_extractor.wait()
-utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
+try:
+utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
+except KeyError: #this happens if there's no 'options' block
+pass
 
 def _iter_files_in_block_path(self, path=None, ext='yml'):
 """Iterator for block descriptions and category trees"""

Re: [Discuss-gnuradio] gnuradio-companion-3.8.0 fails to run

[Marcus Müller]

ah! I missed the part where you said you're not used to Python.

In Python, indentation is structure-defining, and  the error message
sadly doesn't really give context, but it looks like the most probable
explanation is that the line you've inserted is not correctly indented.

Make sure you're using the same characters to indent (spaces) and the
same amount of additional spaces to indent the content of the try:-
block.

Best regards,
Marcus


On Fri, 2019-10-25 at 15:02 +0100, Barry Jackson wrote:
> Update:
> Since last night I have re-created the patch and re-built and this
> time 
> the package built with:
> 
>  self._docstring_extractor.finish()
>  # self._docstring_extractor.wait()
>  try:
>  
> utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
>  except KeyError:   #this happens if there's no 'options'
> block
>   pass
> 
>  def _iter_files_in_block_path(self, path=None, ext='yml'):
>  """Iterator for block descriptions and category trees"""
> 
> However the error is still the same. Commenting out the
> section from "try:" down to "pass" locally the error is exactly the 
> same, as though that bit of code does not get involved.
> 
> Just to be sure this is in 
> /usr/lib/python3.8/site-
> packages/gnuradio/grc/core/platform.py  around 
> line 197
> 

Re: [Discuss-gnuradio] gnuradio-companion-3.8.0 fails to run

[Barry Jackson]

On 24/10/2019 21:18, Håkon Vågsether wrote:

This error message also occurs in one of the GRC tests:

https://github.com/gnuradio/gnuradio/issues/2678

Best regards
Håkon Vågsether




Strange that there has been no response to your bug report since July.

Any other suggestions as to how to work around it? I am not conversant 
with python.


Cheers,
Barry

Re: [Discuss-gnuradio] gnuradio-companion-3.8.0 fails to run

[Barry Jackson]

Update:
Since last night I have re-created the patch and re-built and this time 
the package built with:


self._docstring_extractor.finish()
# self._docstring_extractor.wait()
try:

utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
except KeyError:   #this happens if there's no 'options' block
 pass

def _iter_files_in_block_path(self, path=None, ext='yml'):
"""Iterator for block descriptions and category trees"""

However the error is still the same. Commenting out the
section from "try:" down to "pass" locally the error is exactly the 
same, as though that bit of code does not get involved.


Just to be sure this is in 
/usr/lib/python3.8/site-packages/gnuradio/grc/core/platform.py  around 
line 197

Re: [Discuss-gnuradio] gnuradio-companion-3.8.0 fails to run

[Barry Jackson]

On 24/10/2019 20:36, Müller, Marcus (CEL) wrote:

Hi Barry,

neat, haven't seen that one before, specifically :)
But I've seen a test fail:
https://github.com/gnuradio/gnuradio/issues/2678

Mageia is RPM-based, right? Never used it before, but could you point
me to the .SPEC file you're using to build that package?

Hunch: replace

 utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
with

 try:
  
utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
 except KeyError: #this happens if there's no 'options' block
  pass

and things should work.
I honestly think we could improve the
hide_bokeh_gui_options_if_not_installed to handle None arguments and
use .get('options') instead of ['options']. Willing to pick up on that?

Best regards,
Marcus

On Thu, 2019-10-24 at 19:03 +0100, Barry Jackson wrote:

[baz@jackodesktop ~]$ gnuradio-companion
Traceback (most recent call last):
File "/usr/bin/gnuradio-companion", line 102, in 
  run_main()
File "/usr/bin/gnuradio-companion", line 95, in run_main
  exit(main())
File "/usr/lib/python3.8/site-packages/gnuradio/grc/main.py", line
83, in main
  platform.build_library()
File
"/usr/lib/python3.8/site-packages/gnuradio/grc/core/platform.py", line
197, in build_library
  utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
File "/usr/lib64/python3.8/collections/__init__.py", line 891, in
__getitem__
  return self.__missing__(key)# support subclasses that
define __missing__
File "/usr/lib64/python3.8/collections/__init__.py", line 883, in
__missing__
  raise KeyError(key)
KeyError: 'options'
[baz@jackodesktop ~]$

I found this
https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg69270.html
...which looked promising, but deleting .~.gnuradio changes nothing here.

I have just updated our (Mageia8) package tp py3/qt5 build and hit this
in testing prior to pushing to our dev branch repo.

Any ideas welcome :)

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


Hi Marcus,
No joy.
Using the change as you wrote it with the comment? on the line like:
except KeyError: #this happens if there's no 'options' block

...caused a build error which looked like it was during the docs build 
at the start.


Knowing nothing about python I moved the comment? to the next line after 
'pass' like:

pass  #this happens if there's no 'options' block

(I saw this syntax in other similar structures in the same file)

.. that then built, but the error is the same:

[baz@jackodesktop ~]$ gnuradio-companion
Traceback (most recent call last):
  File 
"/usr/lib/python3.8/site-packages/gnuradio/grc/gui/Application.py", line 
102, in do_activate

self.main_window = MainWindow(self, self.platform)
  File 
"/usr/lib/python3.8/site-packages/gnuradio/grc/gui/MainWindow.py", line 
84, in __init__

generate_modes = platform.get_generate_options()
  File 
"/usr/lib/python3.8/site-packages/gnuradio/grc/core/platform.py", line 
379, in get_generate_options

for param in self.block_classes['options'].parameters_data:
  File "/usr/lib64/python3.8/collections/__init__.py", line 891, in 
__getitem__
return self.__missing__(key)# support subclasses that 
define __missing__
  File "/usr/lib64/python3.8/collections/__init__.py", line 883, in 
__missing__

raise KeyError(key)
KeyError: 'options'

The build errors with the patch as you had it can be seen in this build 
fail:

http://mtf.duckdns.org/pub/linux/barjac/distrib/cauldron/x86_64/log/gnuradio-3.8.0.0-1.3.mga8_bcj.src.rpm/build.0.20191024221952.log

OK I'm off to bed!

Cheers,
Barry

Re: [Discuss-gnuradio] gnuradio-companion-3.8.0 fails to run

[Håkon Vågsether]

This error message also occurs in one of the GRC tests:

https://github.com/gnuradio/gnuradio/issues/2678

Best regards
Håkon Vågsether


tor. 24. okt. 2019, 12:41 skrev Müller, Marcus (CEL) :

> Hi Barry,
>
> neat, haven't seen that one before, specifically :)
> But I've seen a test fail:
> https://github.com/gnuradio/gnuradio/issues/2678
>
> Mageia is RPM-based, right? Never used it before, but could you point
> me to the .SPEC file you're using to build that package?
>
> Hunch: replace
>
>
> utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
> with
>
> try:
>
>  utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
> except KeyError: #this happens if there's no 'options' block
>  pass
>
> and things should work.
> I honestly think we could improve the
> hide_bokeh_gui_options_if_not_installed to handle None arguments and
> use .get('options') instead of ['options']. Willing to pick up on that?
>
> Best regards,
> Marcus
>
> On Thu, 2019-10-24 at 19:03 +0100, Barry Jackson wrote:
> > [baz@jackodesktop ~]$ gnuradio-companion
> > Traceback (most recent call last):
> >File "/usr/bin/gnuradio-companion", line 102, in 
> >  run_main()
> >File "/usr/bin/gnuradio-companion", line 95, in run_main
> >  exit(main())
> >File "/usr/lib/python3.8/site-packages/gnuradio/grc/main.py", line
> > 83, in main
> >  platform.build_library()
> >File
> > "/usr/lib/python3.8/site-packages/gnuradio/grc/core/platform.py", line
> > 197, in build_library
> >
> utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
> >File "/usr/lib64/python3.8/collections/__init__.py", line 891, in
> > __getitem__
> >  return self.__missing__(key)# support subclasses that
> > define __missing__
> >File "/usr/lib64/python3.8/collections/__init__.py", line 883, in
> > __missing__
> >  raise KeyError(key)
> > KeyError: 'options'
> > [baz@jackodesktop ~]$
> >
> > I found this
> > https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg69270.html
> > ...which looked promising, but deleting .~.gnuradio changes nothing here.
> >
> > I have just updated our (Mageia8) package tp py3/qt5 build and hit this
> > in testing prior to pushing to our dev branch repo.
> >
> > Any ideas welcome :)
> >
> > ___
> > 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] gnuradio-companion-3.8.0 fails to run

[CEL]

Hi Barry,

neat, haven't seen that one before, specifically :)
But I've seen a test fail: 
https://github.com/gnuradio/gnuradio/issues/2678

Mageia is RPM-based, right? Never used it before, but could you point
me to the .SPEC file you're using to build that package?

Hunch: replace 

utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
with 

try:
 
utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
except KeyError: #this happens if there's no 'options' block
 pass

and things should work.
I honestly think we could improve the
hide_bokeh_gui_options_if_not_installed to handle None arguments and
use .get('options') instead of ['options']. Willing to pick up on that?

Best regards,
Marcus

On Thu, 2019-10-24 at 19:03 +0100, Barry Jackson wrote:
> [baz@jackodesktop ~]$ gnuradio-companion
> Traceback (most recent call last):
>File "/usr/bin/gnuradio-companion", line 102, in 
>  run_main()
>File "/usr/bin/gnuradio-companion", line 95, in run_main
>  exit(main())
>File "/usr/lib/python3.8/site-packages/gnuradio/grc/main.py", line 
> 83, in main
>  platform.build_library()
>File 
> "/usr/lib/python3.8/site-packages/gnuradio/grc/core/platform.py", line 
> 197, in build_library
>  utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
>File "/usr/lib64/python3.8/collections/__init__.py", line 891, in 
> __getitem__
>  return self.__missing__(key)# support subclasses that 
> define __missing__
>File "/usr/lib64/python3.8/collections/__init__.py", line 883, in 
> __missing__
>  raise KeyError(key)
> KeyError: 'options'
> [baz@jackodesktop ~]$
> 
> I found this
> https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg69270.html
> ...which looked promising, but deleting .~.gnuradio changes nothing here.
> 
> I have just updated our (Mageia8) package tp py3/qt5 build and hit this 
> in testing prior to pushing to our dev branch repo.
> 
> Any ideas welcome :)
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion : File Descriptor Source module usage

[Tom Crane]

On Tue, 23 Jul 2019, Kevin Reid wrote:


On Tue, Jul 23, 2019 at 8:33 PM Tom Crane  wrote:
  Can anyone explain how to use the File Descriptor Source module in
  gnuradio-companion?

  I am trying to write a flow-graph to read data from an arbitrary file,
  chosen via the GUI at run time?  This must be possible, right?  I can't
  see how to do it.


I don't have time to write a full explanation, but note that you want the File 
Source block, not the File Descriptor Source block. The File Descriptor Source 
is only really useful to read from standard input or for use in more complex 
programs than you can write
with GRC.

The File Source block takes a string for the filename. If you create a Variable 
block with a string value, you can enter the ID of the Variable instead of a 
filename, and then change that Variable using GUI in the usual fashion. I 
haven't tested this, but that's
how it should work.


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

Re: [Discuss-gnuradio] gnuradio-companion : File Descriptor Source module usage

[Kevin Reid]

On Tue, Jul 23, 2019 at 8:33 PM Tom Crane  wrote:

> Can anyone explain how to use the File Descriptor Source module in
> gnuradio-companion?
>
> I am trying to write a flow-graph to read data from an arbitrary file,
> chosen via the GUI at run time?  This must be possible, right?  I can't
> see how to do it.
>

I don't have time to write a full explanation, but note that you want the
File Source block, not the File Descriptor Source block. The File
Descriptor Source is only really useful to read from standard input or for
use in more complex programs than you can write with GRC.

The File Source block takes a string for the filename. If you create a
Variable block with a string value, you can enter the ID of the Variable
instead of a filename, and then change that Variable using GUI in the usual
fashion. I haven't tested this, but that's how it should work.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNUradio companion error message

[Michael Dickens]

Hi John_w_g - The error you're encountering indicates that the version of UHD 
isn't compatible with the version of gr-uhd -- which is part of the overall GNU 
Radio install. I'd guess that GNU Radio was installed, and then UHD was 
updated. Generally the solution is to reinstall GNU Radio while keeping the 
version of UHD stable. When you update UHD, do it first then update GNU Radio 
to make sure API compatibility is maintained. Thus, the main question is: how 
are UHD and GNU Radio installed? What version of UHD is installed (GR is at 
3.7.9 according to your note)? Hope this is useful! - MLD

On Tue, Oct 16, 2018, at 2:16 PM, John_w_g wrote:
> Attached is my simple tone_test loopback flow graph, and the system error 
> that is output when I run it.  I have verified correct driver operation by 
> running uhd_usrp_probe (output also attached).  I am running Ubuntu 16.04.5 
> and GRC 3.7.9
> 
> I was previously able to run GRC without this error.  I did an OS update that 
> was advertised.  After the update I received this error (I do not know if it 
> was related).  I ran uhd_usrp_probe and it complained that I had the wrong 
> FPGA version, so I re-ran the FPGA downloader and updated the image,  after 
> that uhd was happy, but this error persists.

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

Re: [Discuss-gnuradio] GNURadio-Companion: Selected drop down option stays "red"

[CEL]

Hi engineerpcp,

I'm not aware of any problems with that block. The most likely
explanation is that you have conflicting installations of GRC block
files. Please make sure that GRC doesn't try to load GRC blocks from a
path you have older versions of GNU Radio installed in. GRC prints the
block paths it looks into at start into its console.

It might be most time-economical to uninstall all GNU Radios you know
you've installed, and then go and look in / for any potentially
clashing GRC files, e.g. via running

find / -type f -iname 'analog_sig*.xml' | less

Best regards,
Marcus

PS: I had a bit of a hard time reading your question. I think adding
more paragraphs would have helped here – line breaks do wonders at
structuring texts.

On Tue, 2018-08-21 at 15:44 +, engineerpcp wrote:
> Hi.  On Fedora, version 28, I always compile gnuradio from source
> while linking to the ettus uhd drivers that I also compile from
> source.  I compile from source since I eventually build my own
> modules, etc. from source.   I've been doing this method since 2014,
> but now after I compile and install gnuradio version 3.7.13.4 or
> 3.7.13.3, I get some errors in gnuradio-companion.   The compile and
> install goes fine, but while using gnuradio-companion it has errors
> now.  The first error is in the analog signal generator block.  See
> reference "1." below for its block description.  The wavetform type
> in this block is marked as "red" when dragged into a gnuradio
> canvas.  I select sinewave, cosine, etc. and it still remains "red". 
> I can set all the values except for the waveform type, which is a
> drop-down menu.  I've used this block for years, and I don't see any
> errors in the compile that would say something is wrong.The
> second similar error in gnuradio-companion is the "waterfall sink". 
> It shows the windowing type as "red" and selecting a windowing type,
> whether Blackman-Harris, Hamming, etc., still keeps the windowing
> type as "red".  Also, this is a drop down menu, which may be the
> souce of the problem.  These blocks are unusuable until the "red"
> type selected goes "black".   Has anyone had this problem?  Is it
> related to a python library?  I'm assuming both problems are related
> to a python library.  Thank you. 
> References: 
> 1.  https://www.gnuradio.org/doc/doxygen/classgr_1_1analog_1_1sig__so
> urce__c.html#details 
> 2. https://www.gnuradio.org/doc/doxygen/classgr_1_1qtgui_1_1waterfall
> __sink__c.html 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio Companion LPF

[Derek Kozel]

Hello Yeo,

You've posted so many different emails it is very hard to keep up with your
questions and who has answered what. Could you please keep related
questions in the same email thread?

For information on underflows and overflows, here is the page of the USRP
manual.
http://files.ettus.com/manual/page_general.html#general_ounotes

I recommend reading all the pages in the General Usage section to get a
better understanding of how UHD and the USRPs work.
http://files.ettus.com/manual/page_devices.html

Yes, Overflows and underflows will affect your results because you will be
missing data.

Derek

On Tue, May 22, 2018 at 11:01 AM, Yeo Jin Kuang Alvin (IA) <
yjink...@dso.org.sg> wrote:

> Hi all,
>
>
>
> What are the disadvantage of having overflows and underflows? I am working
> on radar projects which is in real-time, will these underflows and
> overflows affect my results?  Sorry I am still trying to learn all these.
>
>
>
> Thank you in advanced!
>
>
>
> *From:* Marcus D. Leech [mailto:mle...@ripnet.com]
> *Sent:* Tuesday, 22 May 2018 11:32 AM
>
> *To:* Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] GNURadio Companion LPF
>
>
>
> On 05/21/2018 11:28 PM, Yeo Jin Kuang Alvin (IA) wrote:
>
> Hi all,
>
>
>
> Thank you! I’ve noticed my mistake.
>
>
>
> Now I’ve tried both 5000 and 100e3, instead of overflowing “O”, I see lots
> of “L” late packets.
>
>
>
> Thank you in advanced!
>
> 'L' is from TX side of things.  It's a special variant of 'U', where the
> transmission is time-tagged, and the device time is already past that point
> when
>   the time-tagged packet arrives.
>
>
>
>
>
> *From:* Marcus D. Leech [mailto:mle...@ripnet.com <mle...@ripnet.com>]
> *Sent:* Tuesday, 22 May 2018 11:19 AM
> *To:* Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] GNURadio Companion LPF
>
>
>
> On 05/21/2018 11:14 PM, Yeo Jin Kuang Alvin (IA) wrote:
>
> Hi Marcus,
>
>
>
> Thank you for the quick reply!
>
>
>
> Is there any block in GRC that works with the FPGA in the USRP B210? And I
> have tried lowering the transition width from 1000 to  ~150 but I still see
> overflow, does this means that the only solution to it is to get a faster
> computer?
>
> There are no FPGA-for-B210 blocks in Gnu Radio.  That's not how Gnu Radio
> works.   RFNoC is an exception, but B210 is not an RFNoC-capable radio.
>
> Narrowing the transition width (as a fraction of sample-rate) is precisely
> how you end up with really-long, hard-to-compute, filters.  Try a transition
>   width of 100e3, and see how that does.  That's a roughly 2% fractional
> bandwidth.  Which, in the analog world, would be a pretty "tight" filter.
>
>
>
>
>
>
> Thank you in advanced!
>
>
>
> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+yjinkuan=dso.org...@gnu.org
> <discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org>] *On Behalf Of *Marcus
> D. Leech
> *Sent:* Tuesday, 22 May 2018 11:02 AM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] GNURadio Companion LPF
>
>
>
> On 05/21/2018 10:54 PM, Yeo Jin Kuang Alvin (IA) wrote:
>
> Hi all,
>
>
>
> Apparently, I tried connecting the USRP Source to a Low Pass Filter and to
> a File Sink, I get overflows “OO”. However, when I removed the LPF,
> there is no overflow. The question is, why is this happening? Is the Low
> Pass Filter in GRC done in the FPGA or in the computer itself? I am using
> USRP B210 and my sampling rate is 6MHz.
>
>
>
> Is there a solution to this?
>
>
>
> Thank you in advanced!
>
>
>
> 'O' are caused by the computer not "keeping up".  Gnu Radio is a
> software-defined-radio framework, and all the blocks execute on the PC host.
>
> It is typically the case that new users make low-pass filters with very
> "aggressive" transition bandwidths, which leads to a very
> expensive-to-compute
>   filter.  Try relaxing the transition bandwidth.
>
>
>
>
>
>
>
>
> ___
> 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] GNURadio Companion LPF

[Yeo Jin Kuang Alvin (IA)]

Hi all,

What are the disadvantage of having overflows and underflows? I am working on 
radar projects which is in real-time, will these underflows and overflows 
affect my results?  Sorry I am still trying to learn all these.

Thank you in advanced!

From: Marcus D. Leech [mailto:mle...@ripnet.com]
Sent: Tuesday, 22 May 2018 11:32 AM
To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 11:28 PM, Yeo Jin Kuang Alvin (IA) wrote:
Hi all,

Thank you! I've noticed my mistake.

Now I've tried both 5000 and 100e3, instead of overflowing "O", I see lots of 
"L" late packets.

Thank you in advanced!
'L' is from TX side of things.  It's a special variant of 'U', where the 
transmission is time-tagged, and the device time is already past that point when
  the time-tagged packet arrives.




From: Marcus D. Leech [mailto:mle...@ripnet.com]
Sent: Tuesday, 22 May 2018 11:19 AM
To: Yeo Jin Kuang Alvin (IA); 
discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 11:14 PM, Yeo Jin Kuang Alvin (IA) wrote:
Hi Marcus,

Thank you for the quick reply!

Is there any block in GRC that works with the FPGA in the USRP B210? And I have 
tried lowering the transition width from 1000 to  ~150 but I still see 
overflow, does this means that the only solution to it is to get a faster 
computer?
There are no FPGA-for-B210 blocks in Gnu Radio.  That's not how Gnu Radio 
works.   RFNoC is an exception, but B210 is not an RFNoC-capable radio.

Narrowing the transition width (as a fraction of sample-rate) is precisely how 
you end up with really-long, hard-to-compute, filters.  Try a transition
  width of 100e3, and see how that does.  That's a roughly 2% fractional 
bandwidth.  Which, in the analog world, would be a pretty "tight" filter.





Thank you in advanced!

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] On Behalf Of 
Marcus D. Leech
Sent: Tuesday, 22 May 2018 11:02 AM
To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 10:54 PM, Yeo Jin Kuang Alvin (IA) wrote:
Hi all,

Apparently, I tried connecting the USRP Source to a Low Pass Filter and to a 
File Sink, I get overflows "OO". However, when I removed the LPF, there is 
no overflow. The question is, why is this happening? Is the Low Pass Filter in 
GRC done in the FPGA or in the computer itself? I am using USRP B210 and my 
sampling rate is 6MHz.

Is there a solution to this?

Thank you in advanced!

'O' are caused by the computer not "keeping up".  Gnu Radio is a 
software-defined-radio framework, and all the blocks execute on the PC host.

It is typically the case that new users make low-pass filters with very 
"aggressive" transition bandwidths, which leads to a very expensive-to-compute
  filter.  Try relaxing the transition bandwidth.






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

Re: [Discuss-gnuradio] GNURadio Companion LPF

[Yeo Jin Kuang Alvin (IA)]

Hi Marcus,

Noted with thanks!

Are there any solutions to these to get the LPF working and solve these "U O L" 
issues?

Thank you in advanced!

From: Marcus D. Leech [mailto:mle...@ripnet.com]
Sent: Tuesday, 22 May 2018 11:32 AM
To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 11:28 PM, Yeo Jin Kuang Alvin (IA) wrote:
Hi all,

Thank you! I've noticed my mistake.

Now I've tried both 5000 and 100e3, instead of overflowing "O", I see lots of 
"L" late packets.

Thank you in advanced!
'L' is from TX side of things.  It's a special variant of 'U', where the 
transmission is time-tagged, and the device time is already past that point when
  the time-tagged packet arrives.




From: Marcus D. Leech [mailto:mle...@ripnet.com]
Sent: Tuesday, 22 May 2018 11:19 AM
To: Yeo Jin Kuang Alvin (IA); 
discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 11:14 PM, Yeo Jin Kuang Alvin (IA) wrote:
Hi Marcus,

Thank you for the quick reply!

Is there any block in GRC that works with the FPGA in the USRP B210? And I have 
tried lowering the transition width from 1000 to  ~150 but I still see 
overflow, does this means that the only solution to it is to get a faster 
computer?
There are no FPGA-for-B210 blocks in Gnu Radio.  That's not how Gnu Radio 
works.   RFNoC is an exception, but B210 is not an RFNoC-capable radio.

Narrowing the transition width (as a fraction of sample-rate) is precisely how 
you end up with really-long, hard-to-compute, filters.  Try a transition
  width of 100e3, and see how that does.  That's a roughly 2% fractional 
bandwidth.  Which, in the analog world, would be a pretty "tight" filter.





Thank you in advanced!

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] On Behalf Of 
Marcus D. Leech
Sent: Tuesday, 22 May 2018 11:02 AM
To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 10:54 PM, Yeo Jin Kuang Alvin (IA) wrote:
Hi all,

Apparently, I tried connecting the USRP Source to a Low Pass Filter and to a 
File Sink, I get overflows "OO". However, when I removed the LPF, there is 
no overflow. The question is, why is this happening? Is the Low Pass Filter in 
GRC done in the FPGA or in the computer itself? I am using USRP B210 and my 
sampling rate is 6MHz.

Is there a solution to this?

Thank you in advanced!

'O' are caused by the computer not "keeping up".  Gnu Radio is a 
software-defined-radio framework, and all the blocks execute on the PC host.

It is typically the case that new users make low-pass filters with very 
"aggressive" transition bandwidths, which leads to a very expensive-to-compute
  filter.  Try relaxing the transition bandwidth.






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

Re: [Discuss-gnuradio] GNURadio Companion LPF

[Marcus D. Leech]

On 05/21/2018 11:28 PM, Yeo Jin Kuang Alvin (IA) wrote:


Hi all,

Thank you! I’ve noticed my mistake.

Now I’ve tried both 5000 and 100e3, instead of overflowing “O”, I see 
lots of “L” late packets.


Thank you in advanced!

'L' is from TX side of things.  It's a special variant of 'U', where the 
transmission is time-tagged, and the device time is already past that 
point when

  the time-tagged packet arrives.



*From:*Marcus D. Leech [mailto:mle...@ripnet.com]
*Sent:* Tuesday, 22 May 2018 11:19 AM
*To:* Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 11:14 PM, Yeo Jin Kuang Alvin (IA) wrote:

Hi Marcus,

Thank you for the quick reply!

Is there any block in GRC that works with the FPGA in the USRP
B210? And I have tried lowering the transition width from 1000 to 
~150 but I still see overflow, does this means that the only

solution to it is to get a faster computer?

There are no FPGA-for-B210 blocks in Gnu Radio.  That's not how Gnu 
Radio works.   RFNoC is an exception, but B210 is not an RFNoC-capable 
radio.


Narrowing the transition width (as a fraction of sample-rate) is 
precisely how you end up with really-long, hard-to-compute, filters.  
Try a transition
  width of 100e3, and see how that does.  That's a roughly 2% 
fractional bandwidth.  Which, in the analog world, would be a pretty 
"tight" filter.




Thank you in advanced!

*From:*Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] *On 
Behalf Of *Marcus D. Leech

*Sent:* Tuesday, 22 May 2018 11:02 AM
*To:* discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>
*Subject:* Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 10:54 PM, Yeo Jin Kuang Alvin (IA) wrote:

Hi all,

Apparently, I tried connecting the USRP Source to a Low Pass
Filter and to a File Sink, I get overflows “OO”. However, when
I removed the LPF, there is no overflow. The question is, why is
this happening? Is the Low Pass Filter in GRC done in the FPGA or
in the computer itself? I am using USRP B210 and my sampling rate
is 6MHz.

Is there a solution to this?

Thank you in advanced!

'O' are caused by the computer not "keeping up".  Gnu Radio is a 
software-defined-radio framework, and all the blocks execute on the PC 
host.


It is typically the case that new users make low-pass filters with 
very "aggressive" transition bandwidths, which leads to a very 
expensive-to-compute

  filter.  Try relaxing the transition bandwidth.





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

Re: [Discuss-gnuradio] GNURadio Companion LPF

[Yeo Jin Kuang Alvin (IA)]

Hi all,

Thank you! I've noticed my mistake.

Now I've tried both 5000 and 100e3, instead of overflowing "O", I see lots of 
"L" late packets.

Thank you in advanced!

From: Marcus D. Leech [mailto:mle...@ripnet.com]
Sent: Tuesday, 22 May 2018 11:19 AM
To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 11:14 PM, Yeo Jin Kuang Alvin (IA) wrote:
Hi Marcus,

Thank you for the quick reply!

Is there any block in GRC that works with the FPGA in the USRP B210? And I have 
tried lowering the transition width from 1000 to  ~150 but I still see 
overflow, does this means that the only solution to it is to get a faster 
computer?
There are no FPGA-for-B210 blocks in Gnu Radio.  That's not how Gnu Radio 
works.   RFNoC is an exception, but B210 is not an RFNoC-capable radio.

Narrowing the transition width (as a fraction of sample-rate) is precisely how 
you end up with really-long, hard-to-compute, filters.  Try a transition
  width of 100e3, and see how that does.  That's a roughly 2% fractional 
bandwidth.  Which, in the analog world, would be a pretty "tight" filter.




Thank you in advanced!

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] On Behalf Of 
Marcus D. Leech
Sent: Tuesday, 22 May 2018 11:02 AM
To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 10:54 PM, Yeo Jin Kuang Alvin (IA) wrote:
Hi all,

Apparently, I tried connecting the USRP Source to a Low Pass Filter and to a 
File Sink, I get overflows "OO". However, when I removed the LPF, there is 
no overflow. The question is, why is this happening? Is the Low Pass Filter in 
GRC done in the FPGA or in the computer itself? I am using USRP B210 and my 
sampling rate is 6MHz.

Is there a solution to this?

Thank you in advanced!

'O' are caused by the computer not "keeping up".  Gnu Radio is a 
software-defined-radio framework, and all the blocks execute on the PC host.

It is typically the case that new users make low-pass filters with very 
"aggressive" transition bandwidths, which leads to a very expensive-to-compute
  filter.  Try relaxing the transition bandwidth.




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

Re: [Discuss-gnuradio] GNURadio Companion LPF

[Kevin McQuiggin]

Hi Alvin:

You need to widen the transition bandwidth, not reduce it!  Going from 1000 to 
150 Hz will greatly increase the complexity of the filter.  Try 5000 Hz to see 
if you get better performance.

Kevin

Sent from my iPad

> On May 21, 2018, at 20:14, Yeo Jin Kuang Alvin (IA) <yjink...@dso.org.sg> 
> wrote:
> 
> Hi Marcus,
>  
> Thank you for the quick reply!
>  
> Is there any block in GRC that works with the FPGA in the USRP B210? And I 
> have tried lowering the transition width from 1000 to  ~150 but I still see 
> overflow, does this means that the only solution to it is to get a faster 
> computer?
>  
> Thank you in advanced!
>  
> From: Discuss-gnuradio 
> [mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] On Behalf Of 
> Marcus D. Leech
> Sent: Tuesday, 22 May 2018 11:02 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF
>  
> On 05/21/2018 10:54 PM, Yeo Jin Kuang Alvin (IA) wrote:
> Hi all,
>  
> Apparently, I tried connecting the USRP Source to a Low Pass Filter and to a 
> File Sink, I get overflows “OO”. However, when I removed the LPF, there 
> is no overflow. The question is, why is this happening? Is the Low Pass 
> Filter in GRC done in the FPGA or in the computer itself? I am using USRP 
> B210 and my sampling rate is 6MHz.
>  
> Is there a solution to this?
>  
> Thank you in advanced!
>  
> 'O' are caused by the computer not "keeping up".  Gnu Radio is a 
> software-defined-radio framework, and all the blocks execute on the PC host.
> 
> It is typically the case that new users make low-pass filters with very 
> "aggressive" transition bandwidths, which leads to a very expensive-to-compute
>   filter.  Try relaxing the transition bandwidth.
> 
> 
> 
> ___
> 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] GNURadio Companion LPF

[Marcus D. Leech]

On 05/21/2018 11:14 PM, Yeo Jin Kuang Alvin (IA) wrote:


Hi Marcus,

Thank you for the quick reply!

Is there any block in GRC that works with the FPGA in the USRP B210? 
And I have tried lowering the transition width from 1000 to ~150 but I 
still see overflow, does this means that the only solution to it is to 
get a faster computer?


There are no FPGA-for-B210 blocks in Gnu Radio.  That's not how Gnu 
Radio works.   RFNoC is an exception, but B210 is not an RFNoC-capable 
radio.


Narrowing the transition width (as a fraction of sample-rate) is 
precisely how you end up with really-long, hard-to-compute, filters.  
Try a transition
  width of 100e3, and see how that does.  That's a roughly 2% 
fractional bandwidth.  Which, in the analog world, would be a pretty 
"tight" filter.




Thank you in advanced!

*From:*Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] *On 
Behalf Of *Marcus D. Leech

*Sent:* Tuesday, 22 May 2018 11:02 AM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 10:54 PM, Yeo Jin Kuang Alvin (IA) wrote:

Hi all,

Apparently, I tried connecting the USRP Source to a Low Pass
Filter and to a File Sink, I get overflows “OO”. However, when
I removed the LPF, there is no overflow. The question is, why is
this happening? Is the Low Pass Filter in GRC done in the FPGA or
in the computer itself? I am using USRP B210 and my sampling rate
is 6MHz.

Is there a solution to this?

Thank you in advanced!

'O' are caused by the computer not "keeping up".  Gnu Radio is a 
software-defined-radio framework, and all the blocks execute on the PC 
host.


It is typically the case that new users make low-pass filters with 
very "aggressive" transition bandwidths, which leads to a very 
expensive-to-compute

  filter.  Try relaxing the transition bandwidth.




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

Re: [Discuss-gnuradio] GNURadio Companion LPF

[Yeo Jin Kuang Alvin (IA)]

Hi Marcus,

Thank you for the quick reply!

Is there any block in GRC that works with the FPGA in the USRP B210? And I have 
tried lowering the transition width from 1000 to  ~150 but I still see 
overflow, does this means that the only solution to it is to get a faster 
computer?

Thank you in advanced!

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] On Behalf Of 
Marcus D. Leech
Sent: Tuesday, 22 May 2018 11:02 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GNURadio Companion LPF

On 05/21/2018 10:54 PM, Yeo Jin Kuang Alvin (IA) wrote:
Hi all,

Apparently, I tried connecting the USRP Source to a Low Pass Filter and to a 
File Sink, I get overflows "OO". However, when I removed the LPF, there is 
no overflow. The question is, why is this happening? Is the Low Pass Filter in 
GRC done in the FPGA or in the computer itself? I am using USRP B210 and my 
sampling rate is 6MHz.

Is there a solution to this?

Thank you in advanced!

'O' are caused by the computer not "keeping up".  Gnu Radio is a 
software-defined-radio framework, and all the blocks execute on the PC host.

It is typically the case that new users make low-pass filters with very 
"aggressive" transition bandwidths, which leads to a very expensive-to-compute
  filter.  Try relaxing the transition bandwidth.


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

Re: [Discuss-gnuradio] GNURadio Companion LPF

[Marcus D. Leech]

On 05/21/2018 10:54 PM, Yeo Jin Kuang Alvin (IA) wrote:


Hi all,

Apparently, I tried connecting the USRP Source to a Low Pass Filter 
and to a File Sink, I get overflows “OO”. However, when I removed 
the LPF, there is no overflow. The question is, why is this happening? 
Is the Low Pass Filter in GRC done in the FPGA or in the computer 
itself? I am using USRP B210 and my sampling rate is 6MHz.


Is there a solution to this?

Thank you in advanced!


'O' are caused by the computer not "keeping up".  Gnu Radio is a 
software-defined-radio framework, and all the blocks execute on the PC host.


It is typically the case that new users make low-pass filters with very 
"aggressive" transition bandwidths, which leads to a very 
expensive-to-compute

  filter.  Try relaxing the transition bandwidth.



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

Re: [Discuss-gnuradio] gnuradio-companion -c is documented but not working

[CEL]

Hello Markus,

yep, that's a documentation bug. I'll look up how the manpages are
generated. Possibly, GRC *used* to have this feature (or it *will* have
that feature). 

What you want to achieve can be achieved with a different command line
utility:

grcc [-d target_directory, default=~/.grc_gnuradio] [-e|--execute]
file.grc

Best regards,
Marcus

On Wed, 2018-01-24 at 15:32 +0100, Markus Wirsing wrote:
> Hello,
> 
> I noticed that the manpage for gnuradio-companion on my ubuntu 17.10
> system contains the following section:
> 
>-c, --compile
>   Only compile the GRC file without invoking the GUI.
> Useful  for
>   unit  testing,  running  gnuradio-companion  from a
> Makefile and
>   other command-line scripting.
> 
> Which seems like a very useful feature.
> However, trying to actually use that option results in an error:
> 
> Usage: gnuradio-companion [options] [saved flow graphs]
> 
> gnuradio-companion: error: no such option: -c
> 
> Invoking gnuradio-companion -h also does not mention it:
> Options:
>   --version   show program's version number and exit
>   -h, --help  show this help message and exit
> 
> Is that feature available or not?
> 
> Markus
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion swig error?

[Marcus Müller]

Hi xlf,


On 26.02.2017 20:38, x...@gmx.com wrote:
> did i do something wrong that my post was never authorized? i've been
> watching it for days not knowing what else to do . . . 

I can't see anything.
Anyway, just don't use nabble but sign up directly with your GMX address
to the list – it's much more comfortable than nabble + you actually see
what's happening on the list, and not just what Nabble's list-scraper
makes out of it.

Cheers,
Marcus

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

Re: [Discuss-gnuradio] gnuradio-companion swig error?

[Michael Dickens]

I don't know why your post didn't go through.



The gr-osmosdr port contents look correct.



Your script works for me on my OS X box (admittedly, 10.12 latest).



Let's take the discussion on-list, and I'll help you debug this & if
there's something relevant I'll reply back to the GR list. - MLD


On Sun, Feb 26, 2017, at 02:38 PM, x...@gmx.com wrote:

> did i do something wrong that my post was never authorized? i've been
> watching it for days not knowing what else to do . . .
> 

> that's what i did regarding SoapySDR.

> 

> i must be reading something wrong, because doing "port contents gr-
> osmosdr | grep_osmosdr_swig returns "command not found"
> 

> "port contents gr-osmosdr" gets me:

> 

> "

> Warning: port definitions are more than two weeks old, consider
> updating them by running 'port selfupdate'.
> Port gr-osmosdr contains:

>   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt-
>   hon2.7/site-packages/osmosdr/__init__.py
>   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt-
>   hon2.7/site-packages/osmosdr/__init__.pyc
>   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt-
>   hon2.7/site-packages/osmosdr/__init__.pyo
>   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt-
>   hon2.7/site-packages/osmosdr/_osmosdr_swig.so
>   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt-
>   hon2.7/site-packages/osmosdr/osmocom_siggen_base.py
>   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt-
>   hon2.7/site-packages/osmosdr/osmocom_siggen_base.pyc
>   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt-
>   hon2.7/site-packages/osmosdr/osmocom_siggen_base.pyo
>   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt-
>   hon2.7/site-packages/osmosdr/osmosdr_swig.py
>   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt-
>   hon2.7/site-packages/osmosdr/osmosdr_swig.pyc
>   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt-
>   hon2.7/site-packages/osmosdr/osmosdr_swig.pyo
>   /opt/local/bin/osmocom_fft

>   /opt/local/bin/osmocom_siggen

>   /opt/local/bin/osmocom_siggen_nogui

>   /opt/local/bin/osmocom_spectrum_sense

>   /opt/local/include/osmosdr/api.h

>   /opt/local/include/osmosdr/device.h

>   /opt/local/include/osmosdr/pimpl.h

>   /opt/local/include/osmosdr/ranges.h

>   /opt/local/include/osmosdr/sink.h

>   /opt/local/include/osmosdr/source.h

>   /opt/local/include/osmosdr/swig/osmosdr_swig.i

>   /opt/local/include/osmosdr/swig/osmosdr_swig_doc.i

>   /opt/local/include/osmosdr/time_spec.h

>   /opt/local/lib/libgnuradio-osmosdr.0.1.5git.dylib

>   /opt/local/lib/libgnuradio-osmosdr.dylib

>   /opt/local/lib/pkgconfig/gnuradio-osmosdr.pc

>   /opt/local/share/gnuradio/grc/blocks/osmosdr_sink.xml

>   /opt/local/share/gnuradio/grc/blocks/osmosdr_source.xml

>   /opt/local/share/gnuradio/grc/blocks/rtlsdr_source.xml

> "

> 

> which i see includes a line that seems to indicate what i think you
> indicate i should be looking for?
> 

> i've attached the simple_am_rx.py scipt.

> 

> i'd say thank you  but i think the post rules suggested i don't.


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

Re: [Discuss-gnuradio] gnuradio-companion swig error?

[x...@gmx.com]

did i do something wrong that my post was never authorized? i've been watching 
it for days not knowing what else to do . . . 

that's what i did regarding SoapySDR.

i must be reading something wrong, because doing "port contents gr-osmosdr | 
grep_osmosdr_swig returns "command not found"

"port contents gr-osmosdr" gets me:

"
Warning: port definitions are more than two weeks old, consider updating them 
by running 'port selfupdate'.
Port gr-osmosdr contains:
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/__init__.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/__init__.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/__init__.pyo
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/osmocom_siggen_base.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/osmocom_siggen_base.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/osmocom_siggen_base.pyo
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/osmosdr_swig.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/osmosdr_swig.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/osmosdr_swig.pyo
  /opt/local/bin/osmocom_fft
  /opt/local/bin/osmocom_siggen
  /opt/local/bin/osmocom_siggen_nogui
  /opt/local/bin/osmocom_spectrum_sense
  /opt/local/include/osmosdr/api.h
  /opt/local/include/osmosdr/device.h
  /opt/local/include/osmosdr/pimpl.h
  /opt/local/include/osmosdr/ranges.h
  /opt/local/include/osmosdr/sink.h
  /opt/local/include/osmosdr/source.h
  /opt/local/include/osmosdr/swig/osmosdr_swig.i
  /opt/local/include/osmosdr/swig/osmosdr_swig_doc.i
  /opt/local/include/osmosdr/time_spec.h
  /opt/local/lib/libgnuradio-osmosdr.0.1.5git.dylib
  /opt/local/lib/libgnuradio-osmosdr.dylib
  /opt/local/lib/pkgconfig/gnuradio-osmosdr.pc
  /opt/local/share/gnuradio/grc/blocks/osmosdr_sink.xml
  /opt/local/share/gnuradio/grc/blocks/osmosdr_source.xml
  /opt/local/share/gnuradio/grc/blocks/rtlsdr_source.xml
"

which i see includes a line that seems to indicate what i think you indicate i 
should be looking for?

i've attached the simple_am_rx.py scipt.

i'd say thank you  but i think the post rules suggested i don't.




On Feb 26, 2017, at 12:46 , Michael Dickens [via GnuRadio] 
 wrote:

> According to nabble, your original post has yet to be authorized. I'll 
> append it for completion. 
> 
> So you're running on an older OS X box (10.8), using the libc++ hack for 
> older systems. That should be OK. Most folks I know who use it do it 
> with 10.6 or 10.7, but it should work on 10.8 too. 
> 
> If you wanted gr-osmosdr without SoapySDR, just do "sudo port install 
> gr-osmosdr -soapysdr", and you'll gr-osmosdr with the rest of the 
> default variants included but without SoapySDR. 
> 
> What does "port contents gr-osmosdr | grep _osmosdr_swig" return for 
> you? Hopefully the swig file is installed into 
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/"
>  
> ... if not, there's an issue ... 
> 
> Can you attach the simple_am_rx.py script to a followup email so that we 
> can verify that it works for us? 
> 
> Hope this is useful! - MLD 
> 
> {{{ 
> trying out gnuradio-companion 
> followed a youtube tutorial for a simple am rcvr 
> 
> did not work, error as follows: 
> 
> Generating: '/Users/SDR/simple_am_rx.py' 
> 
> Executing: 
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
>  
> -u /Users/SDR/simple_am_rx.py 
> 
> Traceback (most recent call last): 
>   File "/Users/SDR/simple_am_rx.py", line 33, in  
> import osmosdr 
>   File 
>   
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/__init__.py",
>  
>   line 26, in  
> from osmosdr_swig import * 
>   File 
>   
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/osmosdr_swig.py",
>  
>   line 17, in  
> _osmosdr_swig = swig_import_helper() 
>   File 
>   
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/osmosdr_swig.py",
>  
>   line 16, in swig_import_helper 
> return importlib.import_module('_osmosdr_swig') 
>   File 
>   
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py",
>  
>   line 37, in import_module 
> __import__(name) 
> ImportError: No module named _osmosdr_swig 
> 
> dets: 
> macbookpro 

Re: [Discuss-gnuradio] gnuradio-companion swig error?

[Michael Dickens]

According to nabble, your original post has yet to be authorized. I'll
append it for completion.

So you're running on an older OS X box (10.8), using the libc++ hack for
older systems. That should be OK. Most folks I know who use it do it
with 10.6 or 10.7, but it should work on 10.8 too.

If you wanted gr-osmosdr without SoapySDR, just do "sudo port install
gr-osmosdr -soapysdr", and you'll gr-osmosdr with the rest of the
default variants included but without SoapySDR.

What does "port contents gr-osmosdr | grep _osmosdr_swig" return for
you? Hopefully the swig file is installed into
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/"
... if not, there's an issue ...

Can you attach the simple_am_rx.py script to a followup email so that we
can verify that it works for us?

Hope this is useful! - MLD

{{{
trying out gnuradio-companion 
followed a youtube tutorial for a simple am rcvr 

did not work, error as follows: 

Generating: '/Users/SDR/simple_am_rx.py' 

Executing:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
-u /Users/SDR/simple_am_rx.py 

Traceback (most recent call last): 
  File "/Users/SDR/simple_am_rx.py", line 33, in 
import osmosdr 
  File
  
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/__init__.py",
  line 26, in 
from osmosdr_swig import * 
  File
  
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/osmosdr_swig.py",
  line 17, in 
_osmosdr_swig = swig_import_helper() 
  File
  
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/osmosdr_swig.py",
  line 16, in swig_import_helper 
return importlib.import_module('_osmosdr_swig') 
  File
  
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py",
  line 37, in import_module 
__import__(name) 
ImportError: No module named _osmosdr_swig 

dets: 
macbookpro c2d 
mountain lion 10.8.5 
xQuartz 2.7.11 
XCode 4.6.3 
Macports 2.4.0 
gnuradio 3.7.10.1 
rtl-sdr 20150608_1 

had to do the LibcxxOnOlder Systems: 
https://trac.macports.org/wiki/LibcxxOnOlderSystems

had to do gr-osmosdr portfile mod 
remove SoapySDR from dependencies 

had to do gqrx portfile mod 
set qtname qt5 

did 
sudo port installed swig 
got 
03.0.12_0 

any ideas?
}}}

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

Re: [Discuss-gnuradio] gnuradio-companion swig error?

[x...@gmx.com]

anyone??



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/gnuradio-companion-swig-error-tp62829p62964.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] gnuradio-companion binary not getting installed

[Philip Balister]

I think you need a python-devel package installed. Exact name will be
distro dependent.

Philip

On 11/29/2016 09:34 AM, Jason Matusiak wrote:
> This was really good information Seth, thanks.  I tried the steps
> Nicolas previously mentioned and I had the same problem.  I ran your
> commands and I see gnuradio-companion under the "disabled components" list.
> 
> Looking further up in the output, the thing I see different from your
> list is that I see:
> Dependency ENABLE_PYTHON = OFF
> 
> Why would that be?
> 
> Thanks!
> 
> On 11/28/2016 04:58 PM, Seth Hitefield wrote:
>> Something may have disabled gnuradio-companion in cmake.
>> Can you run: *"cd ~/gnuradio/src/gnuradio/build; cmake .."*?
>>
>> Towards the end of the output you should see:
>>
>> -- ##
>> -- # Gnuradio enabled components
>> -- ##
>>
>> and
>>
>> -- ##
>> -- # Gnuradio disabled components
>> -- ##
>>
>> Which one does gnuradio-companion fall under?
>>
>> You can also check the cmake output for the section where
>> gnuradio-companion is being configured.
>> That will give you an idea of what is going wrong if it is disabled.
>> It should look something like this:
>>
>> -- Configuring gnuradio-companion support...
>> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>> --   Dependency ENABLE_PYTHON = ON
>> --   Dependency PYTHON_MIN_VER_FOUND = TRUE
>> --   Dependency CHEETAH_FOUND = TRUE
>> --   Dependency LXML_FOUND = TRUE
>> --   Dependency PYGTK_FOUND = TRUE
>> --   Dependency NUMPY_FOUND = TRUE
>> --   Enabling gnuradio-companion support.
>> --   Override with -DENABLE_GRC=ON/OFF
>>
>> -- Seth
>>
>>
>> On 11/28/2016 12:57 PM, Jason Matusiak wrote:
>>> I have a fresh install of Ubuntu 14.04 on a tablet and am trying to
>>> install gnuradio via pybombs.  I run "pybombs prefix init ~/gnuradio
>>> -a myprefix -R gnuradio-default" and it seems to complete
>>> successfully.  But if I look into gnuradio/bin, there is no
>>> gnuradio-companion.  Because of that, when I source setup_env.sh and
>>> tab out "gnur", the only thing that auto-completes is
>>> gnuradio-config-info.
>>>
>>> Any idea why the pybombs install acts like it worked, but I don't
>>> have a binary to run?
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] gnuradio-companion binary not getting installed

[Jason Matusiak]

This was really good information Seth, thanks.  I tried the steps 
Nicolas previously mentioned and I had the same problem.  I ran your 
commands and I see gnuradio-companion under the "disabled components" list.


Looking further up in the output, the thing I see different from your 
list is that I see:

Dependency ENABLE_PYTHON = OFF

Why would that be?

Thanks!

On 11/28/2016 04:58 PM, Seth Hitefield wrote:

Something may have disabled gnuradio-companion in cmake.
Can you run: *"cd ~/gnuradio/src/gnuradio/build; cmake .."*?

Towards the end of the output you should see:

-- ##
-- # Gnuradio enabled components
-- ##

and

-- ##
-- # Gnuradio disabled components
-- ##

Which one does gnuradio-companion fall under?

You can also check the cmake output for the section where 
gnuradio-companion is being configured.
That will give you an idea of what is going wrong if it is disabled. 
It should look something like this:


-- Configuring gnuradio-companion support...
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_PYTHON = ON
--   Dependency PYTHON_MIN_VER_FOUND = TRUE
--   Dependency CHEETAH_FOUND = TRUE
--   Dependency LXML_FOUND = TRUE
--   Dependency PYGTK_FOUND = TRUE
--   Dependency NUMPY_FOUND = TRUE
--   Enabling gnuradio-companion support.
--   Override with -DENABLE_GRC=ON/OFF

-- Seth


On 11/28/2016 12:57 PM, Jason Matusiak wrote:
I have a fresh install of Ubuntu 14.04 on a tablet and am trying to 
install gnuradio via pybombs.  I run "pybombs prefix init ~/gnuradio 
-a myprefix -R gnuradio-default" and it seems to complete 
successfully.  But if I look into gnuradio/bin, there is no 
gnuradio-companion.  Because of that, when I source setup_env.sh and 
tab out "gnur", the only thing that auto-completes is 
gnuradio-config-info.


Any idea why the pybombs install acts like it worked, but I don't 
have a binary to run?


___
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] gnuradio-companion binary not getting installed

[Seth Hitefield]

Something may have disabled gnuradio-companion in cmake.
Can you run: *"cd ~/gnuradio/src/gnuradio/build; cmake .."*?

Towards the end of the output you should see:

-- ##
-- # Gnuradio enabled components
-- ##

and

-- ##
-- # Gnuradio disabled components
-- ##

Which one does gnuradio-companion fall under?

You can also check the cmake output for the section where 
gnuradio-companion is being configured.
That will give you an idea of what is going wrong if it is disabled. It 
should look something like this:


-- Configuring gnuradio-companion support...
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_PYTHON = ON
--   Dependency PYTHON_MIN_VER_FOUND = TRUE
--   Dependency CHEETAH_FOUND = TRUE
--   Dependency LXML_FOUND = TRUE
--   Dependency PYGTK_FOUND = TRUE
--   Dependency NUMPY_FOUND = TRUE
--   Enabling gnuradio-companion support.
--   Override with -DENABLE_GRC=ON/OFF

-- Seth


On 11/28/2016 12:57 PM, Jason Matusiak wrote:
I have a fresh install of Ubuntu 14.04 on a tablet and am trying to 
install gnuradio via pybombs.  I run "pybombs prefix init ~/gnuradio 
-a myprefix -R gnuradio-default" and it seems to complete 
successfully.  But if I look into gnuradio/bin, there is no 
gnuradio-companion.  Because of that, when I source setup_env.sh and 
tab out "gnur", the only thing that auto-completes is 
gnuradio-config-info.


Any idea why the pybombs install acts like it worked, but I don't have 
a binary to run?


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




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion binary not getting installed

[Nicolas Cuervo]

Hello Jason,

I just ran the same line that you ran and I see gnuradio-companio in
prefix/bin/ and I can also run it after setting up the environment.

Could you please update the recipes and see if this solves this:

   pybombs recipes update

Also, you can also update pybombs to see if it also helps:

   [sudo] pip install --upgrade git+https://github.com/gnuradio/pybombs.git

Let us know if it this solves your problem,

Cheers,
- Nicolas

On Mon, Nov 28, 2016 at 6:57 PM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> I have a fresh install of Ubuntu 14.04 on a tablet and am trying to
> install gnuradio via pybombs.  I run "pybombs prefix init ~/gnuradio -a
> myprefix -R gnuradio-default" and it seems to complete successfully.  But
> if I look into gnuradio/bin, there is no gnuradio-companion.  Because of
> that, when I source setup_env.sh and tab out "gnur", the only thing that
> auto-completes is gnuradio-config-info.
>
> Any idea why the pybombs install acts like it worked, but I don't have a
> binary to run?
>
> ___
> 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] gnuradio companion Options block ID

[Sebastian Koslowski]

Hey Wayne,

You are right, a check would be good. The same issue can occur for variable 
blocks.

Thanks,
Sebastian 

Sent from BlueMail



On Jun 14, 2016, 15:28, at 15:28, Wayne Roberts  wrote:
>It would seem that the ID entered into options block of gnuradio
>companion
>is used as the class name of the generated python script.  (defaults to
>top_block)
>But there is one source of trouble with that.
>What if I put into ID field some name which could be same as some
>imported
>module.
>This could happen if your working on OOT module, and put into ID of
>options
>block the same name as your OOT module. It gives you the error:
>AttributeError: 'module' object has no attribute 'foobar'
>Perhaps some little check should be put into gnuradio-companion to
>prevent
>the name conflict.
>
>
>
>
>___
>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] gnuradio Companion and Ettus E310, passing parameters

[Tom Rondeau]

On Thu, Jan 7, 2016 at 11:25 AM, Mike Gilmer  wrote:

> I'm running gnuradio companion on Fedora.  I can make the Ettus device UDP
> to gnuradio Companion and display RF. Great.
>
> Now, if possible, I'd like to be able to use the Companion GUI to pass, in
> real-time, parameter changes, like center frequency, sample rate/bandwidth,
> etc. to the embedded device.
>
> Is this possible?
> Mike
>

This is one of the exact use cases we developed ControlPort for. Right now,
it's not going to be the easiest to use. I think Philip has gotten all of
the support for ControlPort into OE at this point, but I'm not sure what it
would take to update your E310 to enable this support right now (I did it
myself, but that's a process...). Also, you'll need the most current GNU
Radio to really support this. However, if you do get all set up with
everything, there are some example scripts to help you out. See:

https://github.com/gnuradio/gnuradio/tree/master/gr-blocks/examples/ctrlport

The usrp_{source,sink}_controller.py code is a command-line program that
connects to a running GNU Radio app with ControlPort enabled that allows
you to set the parameters of a UHD source or sink. So you have an app
running on your E310, you can use this to change the frequency, gain,
antenna, etc.

This isn't the same as building something in GRC with sliders and such.
You'll have to do more work than just that to get ControlPort to work that
way for you.

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

Re: [Discuss-gnuradio] gnuradio Companion and Ettus E310, passing parameters

[Philip Balister]

I'm going to publish a test image with control port for the e310 next
week. I'm upstreaming the changes to OE now and and should be possible
to build GNU Radio with control easily "soon".

Philip

On 01/07/2016 03:30 PM, Tom Rondeau wrote:
> On Thu, Jan 7, 2016 at 11:25 AM, Mike Gilmer  wrote:
> 
>> I'm running gnuradio companion on Fedora.  I can make the Ettus device UDP
>> to gnuradio Companion and display RF. Great.
>>
>> Now, if possible, I'd like to be able to use the Companion GUI to pass, in
>> real-time, parameter changes, like center frequency, sample rate/bandwidth,
>> etc. to the embedded device.
>>
>> Is this possible?
>> Mike
>>
> 
> This is one of the exact use cases we developed ControlPort for. Right now,
> it's not going to be the easiest to use. I think Philip has gotten all of
> the support for ControlPort into OE at this point, but I'm not sure what it
> would take to update your E310 to enable this support right now (I did it
> myself, but that's a process...). Also, you'll need the most current GNU
> Radio to really support this. However, if you do get all set up with
> everything, there are some example scripts to help you out. See:
> 
> https://github.com/gnuradio/gnuradio/tree/master/gr-blocks/examples/ctrlport
> 
> The usrp_{source,sink}_controller.py code is a command-line program that
> connects to a running GNU Radio app with ControlPort enabled that allows
> you to set the parameters of a UHD source or sink. So you have an app
> running on your E310, you can use this to change the frequency, gain,
> antenna, etc.
> 
> This isn't the same as building something in GRC with sliders and such.
> You'll have to do more work than just that to get ControlPort to work that
> way for you.
> 
> Tom
> 
> 
> 
> ___
> 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] Gnuradio-companion

[Marcus Müller]

Hi Sumit,
> We don’t want to install virtual OS  then we will have to manage user for 
> virtual os also.
it's usually a lot easier having a virtual machine where everything is
recent than having to build a recent version of boost, tell UHD (and in
effect, the applications that will later use UHD) to link against that,
carry the .so around and configure your system to runtime-load that
version of boost when running UHD applications, and the system version
elsewhen. That's the worse kind of system management than having a
separate VM. I guess that's why Dennis proposed to make it easier for
you by using a virtual machine.

So, in fact, there's a tool called pybombs, which tries to install every
dependency, and if it can't find one in a sufficient version, builds it
from source, puts everything in a prefix of its own and gives you a
shell script that sets up an environment where the libraries in that
prefix are loaded by default. That is very handy for development (it's
the way I work, even if I don't usually use pybombs), but from a
centralized system management point of view, this is a nightmare,
because every user has its own set of libraries installed somewhere.
It's kind of the opposite of the reason why people pay money for RHEL.

So, from a maintainability point of view, the virtualized OS might be
easier. Now, I'm usually no proponent of using UHD in virtual machines,
as high performance low latency communication with a SDR devices is
really not what VMs are usually optimized for, unless you really know
how to deal with your virtualizer.

I want to point one thing out here: You haven't mentioned that you want
to use a USRP. If you don't, you just don't need UHD. If you do, then
the network attached ones should be fine; if you want to attach one via
USB3, good luck, because RHEL 6.7 still has a 2.6.35 kernel, and I'm not
aware of how much of recent USB host device drivers they have been
backporting.

You'll probably be able to install all of GNU Radio Companion's 
dependencies on RHEL6, but getting a lot of the more recent features of
GNU Radio to run on RHEL6 might require some backporting. That's not
going to be a lot of fun, so maybe you just want to start using GNU
Radio on a platform where everything works out of the box, and port
everything to RHEL6.7 as soon as you really have to.

Best regards,
Marcus

On 19.11.2015 02:25, Sumit Saluja wrote:
> HI Dennis,
> We don’t want to install virtual OS  then we will have to manage user for 
> virtual os also.
>
> Thanks
> Sumit Saluja
>
> -Original Message-
> From: Dennis Glatting [mailto:gnura...@pki2.com] 
> Sent: Wednesday, November 18, 2015 8:03 PM
> To: Sumit Saluja; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Gnuradio-companion
>
> On Wed, 2015-11-18 at 19:54 -0500, Marcus D. Leech wrote:
>> On 11/18/2015 07:16 PM, Sumit Saluja wrote:
>>> Hi Marcus,
>>>  
>>> I am trying to install it on Our departmental cluster which is 
>>> RHEL6.7. Right now we can’t update to  RHEL7  or CENTOS7
>>>
> Can you install CentOS/Debian/Ubuntu/etc in a virtual container?
>
>
>>>  
>>> Thanks
>>> Sumit Saluja
>> Not much we can do, I don't think.  The version of Boost on your 
>> system is not compatible with UHD.
>>
>> You could install compatible boost from source, and try again.
>>
>>
>>>  
>>> From: discuss-gnuradio-bounces+ssaluja=princeton@gnu.org [mailt 
>>> o:discuss-gnuradio-bounces+ssaluja=princeton@gnu.org] On Behalf 
>>> Of Marcus Müller
>>> Sent: Wednesday, November 18, 2015 6:09 PM
>>> To: discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] Gnuradio-companion
>>>  
>>> Dear Sumit. 
>>>
>>> I just noticed this thread:
>>> you're using RHEL 6, which only hast Boost 1.41; UHD cannot build 
>>> with anything below Boost 1.46.
>>>
>>> Is there a particular reason for sticking with this very old 
>>> version, or can you upgrade to RHEL7 or CentOS7?
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 18.11.2015 23:43, Sumit Saluja wrote:
>>> Please see the logs with -v option
>>>
>>>
>>> ./build-gnuradio -v
>>> This script will install Gnu Radio from current GIT sources You will 
>>> require Internet access from the computer on which this script runs. 
>>> You will also require SUDO access. You will require
>>> approximately 500MB of free disk space to perform the build.
>>> 
>>> This script will, as a side-effect, remove any existing Gnu Radio 
>>

Re: [Discuss-gnuradio] Gnuradio-companion

[Sumit Saluja]

If I am building gnuradio manually Iam getting following message
 ##
-- # Gnuradio disabled components
-- ##
--   * gr-ctrlport
--   * gnuradio-companion
--   * gr-comedi
--   * gr-uhd
--   * gr-video-sdl
--   * gr-wxgui
--   * gr-zeromq



If I am building Gnuradio using build-gnuradio script then getting following 
error

> THIS MAY TAKE QUITE SOME TIME <=
Checking for library libusb ...Found library libusb
Checking for library libboost ...Found library libboost
Checking for library libcppunit ...Found library libcppunit
Checking for library libfftw ...Found library libfftw
Checking for library libgsl ...Found library libgsl
Done
This script will fetch Gnu Radio version 3.7/maint from the repositories, along 
with compatible
extras.
Is this OK?yes
Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)
via the Internet
===> THIS MAY TAKE QUITE SOME TIME <=
Fetching Gnu Radio via GIT...Done
Fetching UHD via GIT...Fetching rtl-sdr (rtl-sdr, gr-osmosdr, gr-iqbal, hackrf, 
bladeRF and airspy) via GIT
Done
Starting function uhd_build at: Wed Nov 18 15:44:13 EST 2015
Building UHD...
=> THIS WILL TAKE SOME TIME <=

UHD build apparently failed
Exiting UHD build




Thanks
Sumit Saluja




From: 18740449846 [18740449...@163.com]
Sent: Monday, November 16, 2015 7:56 PM
To: Sumit Saluja
Subject: 回复: [Discuss-gnuradio] Gnuradio-companion

hi
you need give some detail
for example
how do you build the gnuradio-companion and is you conmmand work well show us 
the result
this is useful to solve you problem

-From Ekko


 原始邮件 
主题：[Discuss-gnuradio] Gnuradio-companion
发件人：Sumit Saluja
收件人：discuss-gnuradio@gnu.org
抄送：


Hi,
I am building gnuradio  on RHEL 6 and gnuradio-companion is not enabling .  How 
I Should enable gnuradio-companion
And UHD is not compiling on RHEL6.


Thanks

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

Re: [Discuss-gnuradio] Gnuradio-companion

[Marcus D. Leech]

On 11/18/2015 03:45 PM, Sumit Saluja wrote:

If I am building gnuradio manually Iam getting following message
 ##
-- # Gnuradio disabled components
-- ##
--   * gr-ctrlport
--   * gnuradio-companion
--   * gr-comedi
--   * gr-uhd
--   * gr-video-sdl
--   * gr-wxgui
--   * gr-zeromq



If I am building Gnuradio using build-gnuradio script then getting 
following error


> THIS MAY TAKE QUITE SOME TIME <=
Checking for library libusb ...Found library libusb
Checking for library libboost ...Found library libboost
Checking for library libcppunit ...Found library libcppunit
Checking for library libfftw ...Found library libfftw
Checking for library libgsl ...Found library libgsl
Done
This script will fetch Gnu Radio version 3.7/maint from the 
repositories, along with compatible

extras.
Is this OK?yes
Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)
via the Internet
===> THIS MAY TAKE QUITE SOME TIME <=
Fetching Gnu Radio via GIT...Done
Fetching UHD via GIT...Fetching rtl-sdr (rtl-sdr, gr-osmosdr, 
gr-iqbal, hackrf, bladeRF and airspy) via GIT

Done
Starting function uhd_build at: Wed Nov 18 15:44:13 EST 2015
Building UHD...
=> THIS WILL TAKE SOME TIME <=

UHD build apparently failed
Exiting UHD build




Thanks
Sumit Saluja

If you run build-gnuradio with -v, you'll get more logs, and likely a 
note from Cmake that it couldn't find some depend that 
gnuradio-companion relies on.







*From:* 18740449846 [18740449...@163.com]
*Sent:* Monday, November 16, 2015 7:56 PM
*To:* Sumit Saluja
*Subject:* 回复: [Discuss-gnuradio] Gnuradio-companion

hi
you need give some detail
for example
how do you build the gnuradio-companion and is you conmmand work well 
show us the result

this is useful to solve you problem

-From Ekko


 原始邮件 
主题：[Discuss-gnuradio] Gnuradio-companion
发件人：Sumit Saluja
收件人：discuss-gnuradio@gnu.org
抄送：


Hi,

I am building gnuradio  on RHEL 6 and gnuradio-companion is not
enabling . How I Should enable gnuradio-companion

And UHD is not compiling on RHEL6.

Thanks

Sumit Saluja



___
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] Gnuradio-companion

[Dennis Glatting]

On Wed, 2015-11-18 at 19:54 -0500, Marcus D. Leech wrote:
> On 11/18/2015 07:16 PM, Sumit Saluja wrote:
> > Hi Marcus,
> >  
> > I am trying to install it on Our departmental cluster which is
> > RHEL6.7. Right now we can’t update to  RHEL7  or CENTOS7
> > 

Can you install CentOS/Debian/Ubuntu/etc in a virtual container?


> >  
> > Thanks
> > Sumit Saluja
> Not much we can do, I don't think.  The version of Boost on your
> system is not compatible with UHD.
> 
> You could install compatible boost from source, and try again.
> 
> 
> >  
> > From: discuss-gnuradio-bounces+ssaluja=princeton@gnu.org [mailt
> > o:discuss-gnuradio-bounces+ssaluja=princeton@gnu.org] On Behalf
> > Of Marcus Müller
> > Sent: Wednesday, November 18, 2015 6:09 PM
> > To: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Gnuradio-companion
> >  
> > Dear Sumit. 
> > 
> > I just noticed this thread:
> > you're using RHEL 6, which only hast Boost 1.41; UHD cannot build
> > with anything below Boost 1.46.
> > 
> > Is there a particular reason for sticking with this very old
> > version, or can you upgrade to RHEL7 or CentOS7?
> > 
> > Best regards,
> > Marcus
> > 
> > On 18.11.2015 23:43, Sumit Saluja wrote:
> > Please see the logs with -v option
> > 
> > 
> > ./build-gnuradio -v
> > This script will install Gnu Radio from current GIT sources
> > You will require Internet access from the computer on which this
> > script runs. You will also require SUDO access. You will require
> > approximately 500MB of free disk space to perform the build.
> > 
> > This script will, as a side-effect, remove any existing Gnu Radio
> > installation that was installed from your Linux distribution
> > packages.
> > It must do this to prevent problems due to interference between
> >
> > a linux-distribution-installed Gnu Radio/UHD and one installed from
> > GIT source.
> >
> > 
> > The whole process may take up to two hours to complete, depending
> > on the   
> > capabilities of your system.   
> > 
> > 
> > !!!
> > !
> > NOTE: if you run into problems while running this script, you can
> > re-run it with
> > the --verbose option to produce lots of diagnostic output to help
> > debug problems.
> > This script has been written to anticipate some of the more common
> > problems one might
> > encounter building ANY large, complex software package. But it is
> > not pefect, and
> > there are certainly some situations it could encounter that it
> > cannot deal with  
> > gracefully. Altering the system configuration from something
> > reasonably standard,
> > removing parts of the filesystem, moving system libraries around
> > arbitrarily, etc,   
> > it likely cannot cope with. It is just a script. It isn't intuitive
> > or artificially  
> > intelligent. It tries to make life a little easier for you, but at
> > the end of the day
> > if it runs into trouble, a certain amount of knowledge on your part
> > about
> > system configuration and idiosyncrasies will inevitably be
> > necessary.
> > 
> > 
> > Proceed?yes
> > Starting all functions at: Wed Nov 18 17:38:05 EST 2015
> > SUDO privileges are required   
> > Do you have SUDO privileges?yes
> > Continuing with script 
> > ./build-gnuradio: line 1410: [: 90 
> > 90 
> > 90 
> > 90 
> > 90 
> > 90 
> > 90 
> > 90 
> > 90 
> > 90: integer expression expected
> > Installing prerequisites.  
> > > THIS MAY TAKE QUITE SOME TIME <= 
> > Loaded plugins: refresh-packagekit, security   
> > Se

Re: [Discuss-gnuradio] Gnuradio-companion

[Marcus D. Leech]

On 11/18/2015 08:27 PM, Sumit Saluja wrote:


Hi Marcus,

Then can you please let me know how to enable gnuradio-companion while 
ibuild gnuradio manually. I am bale to build gnuradio manually but it 
is not enabling gnuradio-comapnion.


Thanks

Sumit Saluja

Check the Cmake output--it will tell you why it has disabled 
gnuradio-companion.



*From:*discuss-gnuradio-bounces+ssaluja=princeton@gnu.org 
[mailto:discuss-gnuradio-bounces+ssaluja=princeton@gnu.org] *On 
Behalf Of * Marcus D. Leech

*Sent:* Wednesday, November 18, 2015 7:54 PM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] Gnuradio-companion

On 11/18/2015 07:16 PM, Sumit Saluja wrote:

Hi Marcus,

I am trying to install it on Our departmental cluster which is
RHEL6.7. Right now we can’t update to  RHEL7  or CENTOS7

Thanks

Sumit Saluja

Not much we can do, I don't think.  The version of Boost on your 
system is not compatible with UHD.


You could install compatible boost from source, and try again.



*From:*discuss-gnuradio-bounces+ssaluja=princeton@gnu.org 
<mailto:discuss-gnuradio-bounces+ssaluja=princeton@gnu.org> 
[mailto:discuss-gnuradio-bounces+ssaluja=princeton@gnu.org] *On 
Behalf Of *Marcus Müller

*Sent:* Wednesday, November 18, 2015 6:09 PM
*To:* discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>
*Subject:* Re: [Discuss-gnuradio] Gnuradio-companion

Dear Sumit.

I just noticed this thread:
you're using RHEL 6, which only hast Boost 1.41; UHD cannot build with 
anything below Boost 1.46.


Is there a particular reason for sticking with this very old version, 
or can you upgrade to RHEL7 or CentOS7?


Best regards,
Marcus

On 18.11.2015 23:43, Sumit Saluja wrote:

Please see the logs with -v option


./build-gnuradio -v
This script will install Gnu Radio from current GIT sources
You will require Internet access from the computer on which this
script runs. You will also require SUDO access. You will require
approximately 500MB of free disk space to perform the build.

This script will, as a side-effect, remove any existing Gnu Radio
installation that was installed from your Linux distribution packages.
It must do this to prevent problems due to interference between
a linux-distribution-installed Gnu Radio/UHD and one installed
from GIT source.

The whole process may take up to two hours to complete, depending
on the
capabilities of your system.



NOTE: if you run into problems while running this script, you can
re-run it with
the --verbose option to produce lots of diagnostic output to help
debug problems.
This script has been written to anticipate some of the more common
problems one might
encounter building ANY large, complex software package. But it is
not pefect, and
there are certainly some situations it could encounter that it
cannot deal with
gracefully. Altering the system configuration from something
reasonably standard,
removing parts of the filesystem, moving system libraries around
arbitrarily, etc,
it likely cannot cope with. It is just a script. It isn't
intuitive or artificially
intelligent. It tries to make life a little easier for you, but at
the end of the day
if it runs into trouble, a certain amount of knowledge on your
part about
system configuration and idiosyncrasies will inevitably be necessary.


Proceed?yes
Starting all functions at: Wed Nov 18 17:38:05 EST 2015
SUDO privileges are required
Do you have SUDO privileges?yes
Continuing with script
./build-gnuradio: line 1410: [: 90
90
90
90
90
90
90
90
90
90: integer expression expected
Installing prerequisites.
> THIS MAY TAKE QUITE SOME TIME <=
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: gnuradio*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: libgruel-*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: libgruel*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Group Process
Warning: Group Engineering and Scientific does not exist.
Package flex-2.5.35-9.el6.x86_64 already installed and latest version
Package gcc-4.4.7-16.el6.x86_64 already installed and latest version
Package redhat-rpm-config-9.0.3-44.sl6.noarch already installed
and latest version
Package rpm-build-4.8.0-47.el6.x86_64 already installed and latest
version
Package 1:make-3.81-20.el6.x86_64 already installed and latest
version
Package patch-2.6-6.el6.x86_64 already installed 

Re: [Discuss-gnuradio] Gnuradio-companion

[Sumit Saluja]

HI Dennis,
We don’t want to install virtual OS  then we will have to manage user for 
virtual os also.

Thanks
Sumit Saluja

-Original Message-
From: Dennis Glatting [mailto:gnura...@pki2.com] 
Sent: Wednesday, November 18, 2015 8:03 PM
To: Sumit Saluja; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Gnuradio-companion

On Wed, 2015-11-18 at 19:54 -0500, Marcus D. Leech wrote:
> On 11/18/2015 07:16 PM, Sumit Saluja wrote:
> > Hi Marcus,
> >  
> > I am trying to install it on Our departmental cluster which is 
> > RHEL6.7. Right now we can’t update to  RHEL7  or CENTOS7
> > 

Can you install CentOS/Debian/Ubuntu/etc in a virtual container?


> >  
> > Thanks
> > Sumit Saluja
> Not much we can do, I don't think.  The version of Boost on your 
> system is not compatible with UHD.
> 
> You could install compatible boost from source, and try again.
> 
> 
> >  
> > From: discuss-gnuradio-bounces+ssaluja=princeton@gnu.org [mailt 
> > o:discuss-gnuradio-bounces+ssaluja=princeton@gnu.org] On Behalf 
> > Of Marcus Müller
> > Sent: Wednesday, November 18, 2015 6:09 PM
> > To: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Gnuradio-companion
> >  
> > Dear Sumit. 
> > 
> > I just noticed this thread:
> > you're using RHEL 6, which only hast Boost 1.41; UHD cannot build 
> > with anything below Boost 1.46.
> > 
> > Is there a particular reason for sticking with this very old 
> > version, or can you upgrade to RHEL7 or CentOS7?
> > 
> > Best regards,
> > Marcus
> > 
> > On 18.11.2015 23:43, Sumit Saluja wrote:
> > Please see the logs with -v option
> > 
> > 
> > ./build-gnuradio -v
> > This script will install Gnu Radio from current GIT sources You will 
> > require Internet access from the computer on which this script runs. 
> > You will also require SUDO access. You will require
> > approximately 500MB of free disk space to perform the build.
> > 
> > This script will, as a side-effect, remove any existing Gnu Radio 
> > installation that was installed from your Linux distribution 
> > packages.
> > It must do this to prevent problems due to interference between
> >
> > a linux-distribution-installed Gnu Radio/UHD and one installed from 
> > GIT source.
> >
> > 
> > The whole process may take up to two hours to complete, depending
> > on the   
> > capabilities of your system.   
> > 
> > 
> > !!!
> > !
> > NOTE: if you run into problems while running this script, you can 
> > re-run it with the --verbose option to produce lots of diagnostic 
> > output to help debug problems.
> > This script has been written to anticipate some of the more common 
> > problems one might encounter building ANY large, complex software 
> > package. But it is
> > not pefect, and
> > there are certainly some situations it could encounter that it
> > cannot deal with  
> > gracefully. Altering the system configuration from something
> > reasonably standard,
> > removing parts of the filesystem, moving system libraries around
> > arbitrarily, etc,   
> > it likely cannot cope with. It is just a script. It isn't intuitive 
> > or artificially intelligent. It tries to make life a little easier 
> > for you, but at the end of the day if it runs into trouble, a 
> > certain amount of knowledge on your part
> > about
> > system configuration and idiosyncrasies will inevitably be
> > necessary.
> > 
> > 
> > Proceed?yes
> > Starting all functions at: Wed Nov 18 17:38:05 EST 2015
> > SUDO privileges are required   
> > Do you have SUDO privileges?yes
> > Continuing with script 
> > ./build-gnuradio: line 1410: [: 90 
> > 90 
> > 90 
> > 90 
> > 90 
> > 90 
> > 90 
> > 90 
> > 90  

Re: [Discuss-gnuradio] Gnuradio-companion

[Marcus D. Leech]

On 11/18/2015 07:16 PM, Sumit Saluja wrote:


Hi Marcus,

I am trying to install it on Our departmental cluster which is 
RHEL6.7. Right now we can’t update to  RHEL7  or CENTOS7


Thanks

Sumit Saluja

Not much we can do, I don't think.  The version of Boost on your system 
is not compatible with UHD.


You could install compatible boost from source, and try again.


*From:*discuss-gnuradio-bounces+ssaluja=princeton@gnu.org 
[mailto:discuss-gnuradio-bounces+ssaluja=princeton@gnu.org] *On 
Behalf Of * Marcus Müller

*Sent:* Wednesday, November 18, 2015 6:09 PM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] Gnuradio-companion

Dear Sumit.

I just noticed this thread:
you're using RHEL 6, which only hast Boost 1.41; UHD cannot build with 
anything below Boost 1.46.


Is there a particular reason for sticking with this very old version, 
or can you upgrade to RHEL7 or CentOS7?


Best regards,
Marcus

On 18.11.2015 23:43, Sumit Saluja wrote:

Please see the logs with -v option


./build-gnuradio -v
This script will install Gnu Radio from current GIT sources
You will require Internet access from the computer on which this
script runs. You will also require SUDO access. You will require
approximately 500MB of free disk space to perform the build.

This script will, as a side-effect, remove any existing Gnu Radio
installation that was installed from your Linux distribution packages.
It must do this to prevent problems due to interference between
a linux-distribution-installed Gnu Radio/UHD and one installed
from GIT source.

The whole process may take up to two hours to complete, depending
on the
capabilities of your system.



NOTE: if you run into problems while running this script, you can
re-run it with
the --verbose option to produce lots of diagnostic output to help
debug problems.
This script has been written to anticipate some of the more common
problems one might
encounter building ANY large, complex software package. But it is
not pefect, and
there are certainly some situations it could encounter that it
cannot deal with
gracefully. Altering the system configuration from something
reasonably standard,
removing parts of the filesystem, moving system libraries around
arbitrarily, etc,
it likely cannot cope with. It is just a script. It isn't
intuitive or artificially
intelligent. It tries to make life a little easier for you, but at
the end of the day
if it runs into trouble, a certain amount of knowledge on your
part about
system configuration and idiosyncrasies will inevitably be necessary.


Proceed?yes
Starting all functions at: Wed Nov 18 17:38:05 EST 2015
SUDO privileges are required
Do you have SUDO privileges?yes
Continuing with script
./build-gnuradio: line 1410: [: 90
90
90
90
90
90
90
90
90
90: integer expression expected
Installing prerequisites.
> THIS MAY TAKE QUITE SOME TIME <=
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: gnuradio*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: libgruel-*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: libgruel*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Group Process
Warning: Group Engineering and Scientific does not exist.
Package flex-2.5.35-9.el6.x86_64 already installed and latest version
Package gcc-4.4.7-16.el6.x86_64 already installed and latest version
Package redhat-rpm-config-9.0.3-44.sl6.noarch already installed
and latest version
Package rpm-build-4.8.0-47.el6.x86_64 already installed and latest
version
Package 1:make-3.81-20.el6.x86_64 already installed and latest
version
Package patch-2.6-6.el6.x86_64 already installed and latest version
Package 1:pkgconfig-0.23-9.1.el6.x86_64 already installed and
latest version
Package gettext-0.17-18.el6.x86_64 already installed and latest
version
Package automake-1.11.1-4.el6.noarch already installed and latest
version
Package bison-2.4.1-5.el6.x86_64 already installed and latest version
Package flex-devel-2.5.35-9.el6.x86_64 already installed and
latest version
Package libtool-2.2.6-15.5.el6.x86_64 already installed and latest
version
Package autoconf-2.63-5.1.el6.noarch already installed and latest
version
Package gcc-c++-4.4.7-16.el6.x86_64 already installed and latest
version
Package binutils-2.20.51.0.2-5.43.el6.x86_64 already installed and
latest version
P

Re: [Discuss-gnuradio] Gnuradio-companion

[Sumit Saluja]

Hi Marcus,
Then can you please let me know how to enable gnuradio-companion while ibuild 
gnuradio manually. I am bale to build gnuradio manually but it is not enabling 
gnuradio-comapnion.


Thanks
Sumit Saluja

From: discuss-gnuradio-bounces+ssaluja=princeton@gnu.org 
[mailto:discuss-gnuradio-bounces+ssaluja=princeton@gnu.org] On Behalf Of 
Marcus D. Leech
Sent: Wednesday, November 18, 2015 7:54 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Gnuradio-companion

On 11/18/2015 07:16 PM, Sumit Saluja wrote:
Hi Marcus,

I am trying to install it on Our departmental cluster which is RHEL6.7. Right 
now we can't update to  RHEL7  or CENTOS7

Thanks
Sumit Saluja
Not much we can do, I don't think.  The version of Boost on your system is not 
compatible with UHD.

You could install compatible boost from source, and try again.




From: 
discuss-gnuradio-bounces+ssaluja=princeton@gnu.org<mailto:discuss-gnuradio-bounces+ssaluja=princeton@gnu.org>
 [mailto:discuss-gnuradio-bounces+ssaluja=princeton@gnu.org] On Behalf Of 
Marcus Müller
Sent: Wednesday, November 18, 2015 6:09 PM
To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Gnuradio-companion

Dear Sumit.

I just noticed this thread:
you're using RHEL 6, which only hast Boost 1.41; UHD cannot build with anything 
below Boost 1.46.

Is there a particular reason for sticking with this very old version, or can 
you upgrade to RHEL7 or CentOS7?

Best regards,
Marcus
On 18.11.2015 23:43, Sumit Saluja wrote:
Please see the logs with -v option


./build-gnuradio -v
This script will install Gnu Radio from current GIT sources
You will require Internet access from the computer on which this
script runs. You will also require SUDO access. You will require
approximately 500MB of free disk space to perform the build.

This script will, as a side-effect, remove any existing Gnu Radio
installation that was installed from your Linux distribution packages.
It must do this to prevent problems due to interference between
a linux-distribution-installed Gnu Radio/UHD and one installed from GIT source.

The whole process may take up to two hours to complete, depending on the
capabilities of your system.


NOTE: if you run into problems while running this script, you can re-run it with
the --verbose option to produce lots of diagnostic output to help debug 
problems.
This script has been written to anticipate some of the more common problems one 
might
encounter building ANY large, complex software package. But it is not pefect, 
and
there are certainly some situations it could encounter that it cannot deal with
gracefully. Altering the system configuration from something reasonably 
standard,
removing parts of the filesystem, moving system libraries around arbitrarily, 
etc,
it likely cannot cope with. It is just a script. It isn't intuitive or 
artificially
intelligent. It tries to make life a little easier for you, but at the end of 
the day
if it runs into trouble, a certain amount of knowledge on your part about
system configuration and idiosyncrasies will inevitably be necessary.


Proceed?yes
Starting all functions at: Wed Nov 18 17:38:05 EST 2015
SUDO privileges are required
Do you have SUDO privileges?yes
Continuing with script
./build-gnuradio: line 1410: [: 90
90
90
90
90
90
90
90
90
90: integer expression expected
Installing prerequisites.
> THIS MAY TAKE QUITE SOME TIME <=
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: gnuradio*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: libgruel-*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: libgruel*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Group Process
Warning: Group Engineering and Scientific does not exist.
Package flex-2.5.35-9.el6.x86_64 already installed and latest version
Package gcc-4.4.7-16.el6.x86_64 already installed and latest version
Package redhat-rpm-config-9.0.3-44.sl6.noarch already installed and latest 
version
Package rpm-build-4.8.0-47.el6.x86_64 already installed and latest version
Package 1:make-3.81-20.el6.x86_64 already installed and latest version
Package patch-2.6-6.el6.x86_64 already installed and latest version
Package 1:pkgconfig-0.23-9.1.el6.x86_64 already installed and latest version
Package gettext-0.17-18.el6.x86_64 already installed and latest version
Package automake-1.11.1-4.el6.noarch already installed and latest version
Package bison-2.4.1-5.el6.x86_64 already installed and latest version
Package flex-devel-2.5.35-9.el6.x86_64 already installed and latest version
Package libtool-2.2.6-15.5.el6.x86_64 already installed and latest version
Package autoconf-2.63-5.1.

Re: [Discuss-gnuradio] Gnuradio-companion

[Marcus D. Leech]

done.
remote: Compressing objects: 100% (711/711), done.
remote: Total 1617 (delta 1182), reused 1213 (delta 898)
Receiving objects: 100% (1617/1617), 345.89 KiB | 529.00 KiB/s, done.
Resolving deltas: 100% (1182/1182), done.
Cloning into 'gr-osmosdr'...
remote: Counting objects: 3818, done.
remote: Compressing objects: 100% (2510/2510), done.
remote: Total 3818 (delta 2737), reused 1886 (delta 1270)
Receiving objects: 100% (3818/3818), 925.99 KiB | 876.00 KiB/s, done.
Resolving deltas: 100% (2737/2737), done.
Cloning into 'gr-iqbal'...
remote: Counting objects: 219, done.
remote: Compressing objects: 100% (175/175), done.
remote: Total 219 (delta 109), reused 98 (delta 40)
Receiving objects: 100% (219/219), 130.17 KiB | 0 bytes/s, done.
Resolving deltas: 100% (109/109), done.
Cloning into 'bladeRF'...
remote: Counting objects: 16325, done.
remote: Total 16325 (delta 0), reused 0 (delta 0), pack-reused 16325
Receiving objects: 100% (16325/16325), 6.81 MiB | 1.37 MiB/s, done.
Resolving deltas: 100% (9380/9380), done.
Submodule 'libosmo-dsp' (git://git.osmocom.org/libosmo-dsp) registered 
for path 'libosmo-dsp'

Cloning into 'libosmo-dsp'...
remote: Counting objects: 172, done.
remote: Compressing objects: 100% (106/106), done.
remote: Total 172 (delta 89), reused 123 (delta 58)
Receiving objects: 100% (172/172), 60.12 KiB | 0 bytes/s, done.
Resolving deltas: 100% (89/89), done.
Submodule path 'libosmo-dsp': checked out 
'f9df8894c72cbd491bdd2f6d4cbea95c46810267'

Cloning into 'hackrf'...
remote: Counting objects: 9629, done.
remote: Total 9629 (delta 0), reused 0 (delta 0), pack-reused 9629
Receiving objects: 100% (9629/9629), 24.49 MiB | 21.42 MiB/s, done.
Resolving deltas: 100% (6741/6741), done.
Cloning into 'host'...
remote: Counting objects: 626, done.
remote: Total 626 (delta 0), reused 0 (delta 0), pack-reused 626
Receiving objects: 100% (626/626), 587.24 KiB | 0 bytes/s, done.
Resolving deltas: 100% (452/452), done.
Done
Starting function uhd_build at: Wed Nov 18 17:41:12 EST 2015
Building UHD...
=> THIS WILL TAKE SOME TIME <=

-- The CXX compiler identification is GNU 4.4.7
-- The C compiler identification is GNU 4.4.7
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
--
-- Configuring the python interpreter...
-- Found PythonInterp: /usr/lib/python2.7/bin/python (found version 
"2.7.8")

-- Python interpreter: /usr/lib/python2.7/bin/python
-- Override with: -DPYTHON_EXECUTABLE=
-- Using UHD Images Directory: OFF
-- Build type not specified: defaulting to release.
-- Performing Test HAVE_VISIBILITY_HIDDEN
-- Performing Test HAVE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_VISIBILITY_INLINES_HIDDEN
-- Performing Test HAVE_VISIBILITY_INLINES_HIDDEN - Success
--
-- Configuring Boost C++ Libraries...
-- Could NOT find Boost
-- Boost include directories: /usr/include
-- Boost library directories: /usr/lib64
-- Boost libraries:
-- Looking for log2
-- Looking for log2 - found
--
-- Python checking for Python version 2.6 or greater
-- Python checking for Python version 2.6 or greater - found
--
-- Python checking for Mako templates 0.4 or greater
-- Python checking for Mako templates 0.4 or greater - found
--
-- Configuring LibUHD support...
--   Dependency Boost_FOUND = 0
--   Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
--   Dependency HAVE_PYTHON_MODULE_MAKO = TRUE
CMake Error at cmake/Modules/UHDComponent.cmake:51 (MESSAGE):
  Dependencies for required component LibUHD not met.
Call Stack (most recent call first):
  CMakeLists.txt:279 (LIBUHD_REGISTER_COMPONENT)


-- Configuring incomplete, errors occurred!
See also "/home/ssaluja/test/uhd/host/build/CMakeFiles/CMakeOutput.log".
make: *** No rule to make target `clean'.  Stop.
make: *** No targets specified and no makefile found.  Stop.
UHD build apparently failed
Exiting UHD build

===
If you have found this script useful and time-saving, consider a
donation to help me keep build-gnuradio, simple_ra, SIDsuite,
meteor_detector, simple_fm_rcv, and multimode maintained and up to date.
A simple paypal transfer to mle...@ripnet.com is all you need to do.
==
Send success/fail info to sbrac.org?


*From:* discuss-gnuradio-bounces+ssaluja=princeton@gnu.org 
[discuss-gnuradio-bounces+ssaluja=princeton@gnu.org] on behalf of 
Marcus D. Leech [mle...@ripnet.com]

*Sent:* Wednesday, November 18, 2015 3:58 PM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] Gnuradio-companion

On 1

Re: [Discuss-gnuradio] Gnuradio-companion

[Sumit Saluja]

Hi Marcus,

I am trying to install it on Our departmental cluster which is RHEL6.7. Right 
now we can't update to  RHEL7  or CENTOS7

Thanks
Sumit Saluja

From: discuss-gnuradio-bounces+ssaluja=princeton@gnu.org 
[mailto:discuss-gnuradio-bounces+ssaluja=princeton@gnu.org] On Behalf Of 
Marcus Müller
Sent: Wednesday, November 18, 2015 6:09 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Gnuradio-companion

Dear Sumit.

I just noticed this thread:
you're using RHEL 6, which only hast Boost 1.41; UHD cannot build with anything 
below Boost 1.46.

Is there a particular reason for sticking with this very old version, or can 
you upgrade to RHEL7 or CentOS7?

Best regards,
Marcus
On 18.11.2015 23:43, Sumit Saluja wrote:
Please see the logs with -v option


./build-gnuradio -v
This script will install Gnu Radio from current GIT sources
You will require Internet access from the computer on which this
script runs. You will also require SUDO access. You will require
approximately 500MB of free disk space to perform the build.

This script will, as a side-effect, remove any existing Gnu Radio
installation that was installed from your Linux distribution packages.
It must do this to prevent problems due to interference between
a linux-distribution-installed Gnu Radio/UHD and one installed from GIT source.

The whole process may take up to two hours to complete, depending on the
capabilities of your system.


NOTE: if you run into problems while running this script, you can re-run it with
the --verbose option to produce lots of diagnostic output to help debug 
problems.
This script has been written to anticipate some of the more common problems one 
might
encounter building ANY large, complex software package. But it is not pefect, 
and
there are certainly some situations it could encounter that it cannot deal with
gracefully. Altering the system configuration from something reasonably 
standard,
removing parts of the filesystem, moving system libraries around arbitrarily, 
etc,
it likely cannot cope with. It is just a script. It isn't intuitive or 
artificially
intelligent. It tries to make life a little easier for you, but at the end of 
the day
if it runs into trouble, a certain amount of knowledge on your part about
system configuration and idiosyncrasies will inevitably be necessary.


Proceed?yes
Starting all functions at: Wed Nov 18 17:38:05 EST 2015
SUDO privileges are required
Do you have SUDO privileges?yes
Continuing with script
./build-gnuradio: line 1410: [: 90
90
90
90
90
90
90
90
90
90: integer expression expected
Installing prerequisites.
> THIS MAY TAKE QUITE SOME TIME <=
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: gnuradio*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: libgruel-*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Remove Process
No Match for argument: libgruel*
No Packages marked for removal
Loaded plugins: refresh-packagekit, security
Setting up Group Process
Warning: Group Engineering and Scientific does not exist.
Package flex-2.5.35-9.el6.x86_64 already installed and latest version
Package gcc-4.4.7-16.el6.x86_64 already installed and latest version
Package redhat-rpm-config-9.0.3-44.sl6.noarch already installed and latest 
version
Package rpm-build-4.8.0-47.el6.x86_64 already installed and latest version
Package 1:make-3.81-20.el6.x86_64 already installed and latest version
Package patch-2.6-6.el6.x86_64 already installed and latest version
Package 1:pkgconfig-0.23-9.1.el6.x86_64 already installed and latest version
Package gettext-0.17-18.el6.x86_64 already installed and latest version
Package automake-1.11.1-4.el6.noarch already installed and latest version
Package bison-2.4.1-5.el6.x86_64 already installed and latest version
Package flex-devel-2.5.35-9.el6.x86_64 already installed and latest version
Package libtool-2.2.6-15.5.el6.x86_64 already installed and latest version
Package autoconf-2.63-5.1.el6.noarch already installed and latest version
Package gcc-c++-4.4.7-16.el6.x86_64 already installed and latest version
Package binutils-2.20.51.0.2-5.43.el6.x86_64 already installed and latest 
version
Package patchutils-0.3.1-3.1.el6.x86_64 already installed and latest version
Package byacc-1.9.20070509-7.el6.x86_64 already installed and latest version
Package indent-2.2.10-7.el6.x86_64 already installed and latest version
Package systemtap-2.7-2.el6.x86_64 already installed and latest version
Package diffstat-1.51-2.el6.x86_64 already installed and latest version
Package elfutils-0.161-3.el6.x86_64 already installed and latest version
Package cvs-1.11.23-16.el6.x86_64 already installed and latest version
Package rcs-5.7-37.el6.x86_64 already installed and latest version
Package subversion-1.6.11-15

Re: [Discuss-gnuradio] Gnuradio-companion

[Marcus Müller]

   
> Cloning into 'gr-osmosdr'...
> remote: Counting objects: 3818, done.
> remote: Compressing objects: 100% (2510/2510), done.
> remote: Total 3818 (delta 2737), reused 1886 (delta 1270)
> Receiving objects: 100% (3818/3818), 925.99 KiB | 876.00 KiB/s, done.
> Resolving deltas: 100% (2737/2737), done.   
> Cloning into 'gr-iqbal'...  
> remote: Counting objects: 219, done.
> remote: Compressing objects: 100% (175/175), done.
> remote: Total 219 (delta 109), reused 98 (delta 40)
> Receiving objects: 100% (219/219), 130.17 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (109/109), done.
> Cloning into 'bladeRF'...  
> remote: Counting objects: 16325, done.
> remote: Total 16325 (delta 0), reused 0 (delta 0), pack-reused 16325
> Receiving objects: 100% (16325/16325), 6.81 MiB | 1.37 MiB/s, done.
> Resolving deltas: 100% (9380/9380), done.  
> Submodule 'libosmo-dsp' (git://git.osmocom.org/libosmo-dsp) registered
> for path 'libosmo-dsp'
> Cloning into
> 'libosmo-dsp'...  
>  
> remote: Counting objects: 172, done.
> remote: Compressing objects: 100% (106/106), done.
> remote: Total 172 (delta 89), reused 123 (delta 58)
> Receiving objects: 100% (172/172), 60.12 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (89/89), done. 
> Submodule path 'libosmo-dsp': checked out
> 'f9df8894c72cbd491bdd2f6d4cbea95c46810267'
> Cloning into
> 'hackrf'...   
> remote: Counting objects: 9629, done.
> remote: Total 9629 (delta 0), reused 0 (delta 0), pack-reused 9629
> Receiving objects: 100% (9629/9629), 24.49 MiB | 21.42 MiB/s, done.
> Resolving deltas: 100% (6741/6741), done. 
> Cloning into 'host'...
> remote: Counting objects: 626, done.
> remote: Total 626 (delta 0), reused 0 (delta 0), pack-reused 626
> Receiving objects: 100% (626/626), 587.24 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (452/452), done.
> Done   
> Starting function uhd_build at: Wed Nov 18 17:41:12 EST 2015   
> Building UHD...
> => THIS WILL TAKE SOME TIME <= 
>
> -- The CXX compiler identification is GNU 4.4.7
> -- The C compiler identification is GNU 4.4.7 
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info 
> -- Detecting CXX compiler ABI info - done  
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> --
> -- Configuring the python interpreter...
> -- Found PythonInterp: /usr/lib/python2.7/bin/python (found version
> "2.7.8")
> -- Python interpreter: /usr/lib/python2.7/bin/python
> -- Override with: -DPYTHON_EXECUTABLE=
> -- Using UHD Images Directory: OFF
> -- Build type not specified: defaulting to release.
> -- Performing Test HAVE_VISIBILITY_HIDDEN
> -- Performing Test HAVE_VISIBILITY_HIDDEN - Success
> -- Performing Test HAVE_VISIBILITY_INLINES_HIDDEN
> -- Performing Test HAVE_VISIBILITY_INLINES_HIDDEN - Success
> --
> -- Configuring Boost C++ Libraries...
> -- Could NOT find Boost
> -- Boost include directories: /usr/include
> -- Boost library directories: /usr/lib64
> -- Boost libraries:
> -- Looking for log2
> -- Looking for log2 - found
> --
> -- Python checking for Python version 2.6 or greater
> -- Python checking for Python version 2.6 or greater - found
> --
> -- Python checking for Mako templates 0.4 or greater
> -- Python checking for Mako templates 0.4 or greater - found
> --
> -- Configuring LibUHD support...
> --   Dependency Boost_FOUND = 0
> --   Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
> --   Dependency HAVE_PYTHON_MODULE_MAKO = TRUE
> CMake Error at cmake/Modules/UHDComponent.cmake:51 (MESSAGE):
>   Dependencies for required component LibUHD not met.
> Call Stack (most recent call first):
>   CMakeLists.txt:279 (LIBUHD_REGISTER_COMPONENT)
>
>
> -- Configuring incomplete, errors occurred!
> See also "/home/ssaluja/test/uhd/host/build/CMakeFiles/CMakeOutput.log".
> make: *** No rule to make target `clean'.  Stop.
> make: *** No targets specified and no makefile found.  Stop.
> UHD buil

Re: [Discuss-gnuradio] Gnuradio-companion

[Sumit Saluja]

 1213 (delta 898)
Receiving objects: 100% (1617/1617), 345.89 KiB | 529.00 KiB/s, done.
Resolving deltas: 100% (1182/1182), done.
Cloning into 'gr-osmosdr'...
remote: Counting objects: 3818, done.
remote: Compressing objects: 100% (2510/2510), done.
remote: Total 3818 (delta 2737), reused 1886 (delta 1270)
Receiving objects: 100% (3818/3818), 925.99 KiB | 876.00 KiB/s, done.
Resolving deltas: 100% (2737/2737), done.
Cloning into 'gr-iqbal'...
remote: Counting objects: 219, done.
remote: Compressing objects: 100% (175/175), done.
remote: Total 219 (delta 109), reused 98 (delta 40)
Receiving objects: 100% (219/219), 130.17 KiB | 0 bytes/s, done.
Resolving deltas: 100% (109/109), done.
Cloning into 'bladeRF'...
remote: Counting objects: 16325, done.
remote: Total 16325 (delta 0), reused 0 (delta 0), pack-reused 16325
Receiving objects: 100% (16325/16325), 6.81 MiB | 1.37 MiB/s, done.
Resolving deltas: 100% (9380/9380), done.
Submodule 'libosmo-dsp' (git://git.osmocom.org/libosmo-dsp) registered for path 
'libosmo-dsp'
Cloning into 'libosmo-dsp'...
remote: Counting objects: 172, done.
remote: Compressing objects: 100% (106/106), done.
remote: Total 172 (delta 89), reused 123 (delta 58)
Receiving objects: 100% (172/172), 60.12 KiB | 0 bytes/s, done.
Resolving deltas: 100% (89/89), done.
Submodule path 'libosmo-dsp': checked out 
'f9df8894c72cbd491bdd2f6d4cbea95c46810267'
Cloning into 'hackrf'...
remote: Counting objects: 9629, done.
remote: Total 9629 (delta 0), reused 0 (delta 0), pack-reused 9629
Receiving objects: 100% (9629/9629), 24.49 MiB | 21.42 MiB/s, done.
Resolving deltas: 100% (6741/6741), done.
Cloning into 'host'...
remote: Counting objects: 626, done.
remote: Total 626 (delta 0), reused 0 (delta 0), pack-reused 626
Receiving objects: 100% (626/626), 587.24 KiB | 0 bytes/s, done.
Resolving deltas: 100% (452/452), done.
Done
Starting function uhd_build at: Wed Nov 18 17:41:12 EST 2015
Building UHD...
=> THIS WILL TAKE SOME TIME <=

-- The CXX compiler identification is GNU 4.4.7
-- The C compiler identification is GNU 4.4.7
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
--
-- Configuring the python interpreter...
-- Found PythonInterp: /usr/lib/python2.7/bin/python (found version "2.7.8")
-- Python interpreter: /usr/lib/python2.7/bin/python
-- Override with: -DPYTHON_EXECUTABLE=
-- Using UHD Images Directory: OFF
-- Build type not specified: defaulting to release.
-- Performing Test HAVE_VISIBILITY_HIDDEN
-- Performing Test HAVE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_VISIBILITY_INLINES_HIDDEN
-- Performing Test HAVE_VISIBILITY_INLINES_HIDDEN - Success
--
-- Configuring Boost C++ Libraries...
-- Could NOT find Boost
-- Boost include directories: /usr/include
-- Boost library directories: /usr/lib64
-- Boost libraries:
-- Looking for log2
-- Looking for log2 - found
--
-- Python checking for Python version 2.6 or greater
-- Python checking for Python version 2.6 or greater - found
--
-- Python checking for Mako templates 0.4 or greater
-- Python checking for Mako templates 0.4 or greater - found
--
-- Configuring LibUHD support...
--   Dependency Boost_FOUND = 0
--   Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
--   Dependency HAVE_PYTHON_MODULE_MAKO = TRUE
CMake Error at cmake/Modules/UHDComponent.cmake:51 (MESSAGE):
  Dependencies for required component LibUHD not met.
Call Stack (most recent call first):
  CMakeLists.txt:279 (LIBUHD_REGISTER_COMPONENT)


-- Configuring incomplete, errors occurred!
See also "/home/ssaluja/test/uhd/host/build/CMakeFiles/CMakeOutput.log".
make: *** No rule to make target `clean'.  Stop.
make: *** No targets specified and no makefile found.  Stop.
UHD build apparently failed
Exiting UHD build

===
If you have found this script useful and time-saving, consider a
donation to help me keep build-gnuradio, simple_ra, SIDsuite,
meteor_detector, simple_fm_rcv, and multimode maintained and up to date.
A simple paypal transfer to mle...@ripnet.com is all you need to do.
==
Send success/fail info to sbrac.org?


From: discuss-gnuradio-bounces+ssaluja=princeton@gnu.org 
[discuss-gnuradio-bounces+ssaluja=princeton@gnu.org] on behalf of Marcus D. 
Leech [mle...@ripnet.com]
Sent: Wednesday, November 18, 2015 3:58 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Gnuradio-companion

On 11/18/2015 03:45 PM, Sumit Saluja wrote:
If I am building gnuradio manually Iam getting following message
 ###

Re: [Discuss-gnuradio] Gnuradio-companion

[Marcus Müller]

I'd like to emphasize on the possibilities for self-debug, in this case.
GNU Radio's cmake run closely describes which dependencies were missing
and which components therefore got disabled.
GRC needs python > 2.5 (I strongly recommend using 2.7 for compatibility
with out of tree modules),
python-cheetah (which you'll probably need to install via EPEL),
python-lxml, and numpy.

Best regards,
Marcus

On 17.11.2015 07:57, Chris Kuethe wrote:
> To amplify what Tom said, if PyBOMBS fails to compile, please increase
> its log level by adding "-v -v -v", capture the full output, upload it
> to something like pastebin and post a link.
>
> I don't have any RHEL6 machines handy but my F22 machine is able to
> build enough pieces to get gnuradio-companion to run. In general, Red
> Hat like distribution haven't got as much attention as Debian-like
> ones, but if you can give us a good bug report and can test patches,
> we can probably help fix it.
>
> -C
>
> On Mon, Nov 16, 2015 at 6:24 PM, Tom Rondeau  wrote:
>> On Mon, Nov 16, 2015 at 12:47 PM, Sumit Saluja 
>> wrote:
>>> Hi,
>>>
>>> I am building gnuradio  on RHEL 6 and gnuradio-companion is not enabling .
>>> How I Should enable gnuradio-companion
>>>
>>> And UHD is not compiling on RHEL6.
>>>
>>>
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Sumit Saluja
>>
>>
>> Install using PyBOMBS. It should know how to get the important packages for
>> everything.
>>
>> If that doesn't work, you should look at the output of cmake, to to the
>> gnuradio-companion section, and look at what's failing.
>>
>> Tom
>>
>>
>> ___
>> 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] Gnuradio-companion

[Tom Rondeau]

On Mon, Nov 16, 2015 at 12:47 PM, Sumit Saluja 
wrote:

> Hi,
>
> I am building gnuradio  on RHEL 6 and gnuradio-companion is not enabling
> .  How I Should enable gnuradio-companion
>
> And UHD is not compiling on RHEL6.
>
>
>
>
>
> Thanks
>
>
>
> Sumit Saluja
>


Install using PyBOMBS. It should know how to get the important packages for
everything.

If that doesn't work, you should look at the output of cmake, to to the
gnuradio-companion section, and look at what's failing.

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

Re: [Discuss-gnuradio] Gnuradio-companion

[Chris Kuethe]

To amplify what Tom said, if PyBOMBS fails to compile, please increase
its log level by adding "-v -v -v", capture the full output, upload it
to something like pastebin and post a link.

I don't have any RHEL6 machines handy but my F22 machine is able to
build enough pieces to get gnuradio-companion to run. In general, Red
Hat like distribution haven't got as much attention as Debian-like
ones, but if you can give us a good bug report and can test patches,
we can probably help fix it.

-C

On Mon, Nov 16, 2015 at 6:24 PM, Tom Rondeau  wrote:
> On Mon, Nov 16, 2015 at 12:47 PM, Sumit Saluja 
> wrote:
>>
>> Hi,
>>
>> I am building gnuradio  on RHEL 6 and gnuradio-companion is not enabling .
>> How I Should enable gnuradio-companion
>>
>> And UHD is not compiling on RHEL6.
>>
>>
>>
>>
>>
>> Thanks
>>
>>
>>
>> Sumit Saluja
>
>
>
> Install using PyBOMBS. It should know how to get the important packages for
> everything.
>
> If that doesn't work, you should look at the output of cmake, to to the
> gnuradio-companion section, and look at what's failing.
>
> Tom
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

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

Re: [Discuss-gnuradio] gnuradio-companion development

[Martin Braun]

Albin,

it's all here. There's a working group for GRC development, headed by
Sebastian Koslowski. There's also issues on our issue tracker and a
roadmap on the wiki
http://gnuradio.org/redmine/projects/gnuradio/wiki/GRCroadmap.

M

On 07/30/2015 08:11 AM, Albin Stigö wrote:
 Hi,
 
 Is there a separate list for gnuradio-companion development? I'm
 interested in taking part...
 
 --Albin
 
 ___
 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] gnuradio-companion development

[Albin Stigö]

Ok, great to know there are some other mac users... I have
reimplemented some blocks using Apples Accelerate framework..
theoretically they should perform better on apple hardware although I
havn't done any benchmarks. I will try to release those...

Also knowing there are other mac users will definitely provide some
motivation :-)

--Albin

On Thu, Jul 30, 2015 at 8:31 PM, Tom Rondeau t...@trondeau.com wrote:
 On Thu, Jul 30, 2015 at 1:21 PM, Albin Stigö albin.st...@gmail.com wrote:

 Hi Seth,

 I'm fairly new to gnuradio but I've spent the last couple of weeks
 digging through the code of the runtime and grc. GRC doesn't work that
 well on my macbook because of issues with qt and gtk2 (especially
 hidpi retina displays)...

 I suspect there are very few gnuradio users on mac but I became
 interested in writing a Cocoa port of grc, if only for learning more
 about SDR (this is a hobby for me). Cocoa is very well suited for
 writing these kinds of visual applications (unfortunately they are not
 really portable, or very limited so, using gnustep)



 Not true. Quite a few mac users.



 A QT port sounds really interesting as the model layer could be
 separated and reused in a Cocoa app.

 It would also be really neat if it was possible to test the flow graph
 directly/dynamically without using python (dynamically build it in gcc
 using the c++ api, perhaps in a separate process)... Although I
 realize this is a much larger undertaking.

 I recently found this and thought it was quite inspiring (web app):
 http://www.pjrc.com/teensy/gui/

 --Albin


 A principle of the redesign is to separate the GUI elements from the actual
 methods, so yes, hopefully this leads into an easier way to redesign to GUI
 part for more native support in, say, OS X.

 Tom




 On Thu, Jul 30, 2015 at 6:04 PM, Seth Hitefield sd...@vt.edu wrote:
  Albin,
 
  What part are you looking to work on? I think there are a few new
  features being worked on for the current version, and Hopefully we are 
  going
  to start ramping up on the qt port again soon.
 
  -- Seth
 
  Sent from my iPhone
 
  On Jul 30, 2015, at 11:11 AM, Albin Stigö albin.st...@gmail.com
  wrote:
 
  Hi,
 
  Is there a separate list for gnuradio-companion development? I'm
  interested in taking part...
 
  --Albin
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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



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

Re: [Discuss-gnuradio] gnuradio-companion development

[Tom Rondeau]

On Thu, Jul 30, 2015 at 1:21 PM, Albin Stigö albin.st...@gmail.com wrote:

 Hi Seth,

 I'm fairly new to gnuradio but I've spent the last couple of weeks
 digging through the code of the runtime and grc. GRC doesn't work that
 well on my macbook because of issues with qt and gtk2 (especially
 hidpi retina displays)...

 I suspect there are very few gnuradio users on mac but I became
 interested in writing a Cocoa port of grc, if only for learning more
 about SDR (this is a hobby for me). Cocoa is very well suited for
 writing these kinds of visual applications (unfortunately they are not
 really portable, or very limited so, using gnustep)



Not true. Quite a few mac users.



 A QT port sounds really interesting as the model layer could be
 separated and reused in a Cocoa app.

 It would also be really neat if it was possible to test the flow graph
 directly/dynamically without using python (dynamically build it in gcc
 using the c++ api, perhaps in a separate process)... Although I
 realize this is a much larger undertaking.

 I recently found this and thought it was quite inspiring (web app):
 http://www.pjrc.com/teensy/gui/

 --Albin


A principle of the redesign is to separate the GUI elements from the actual
methods, so yes, hopefully this leads into an easier way to redesign to GUI
part for more native support in, say, OS X.

Tom




 On Thu, Jul 30, 2015 at 6:04 PM, Seth Hitefield sd...@vt.edu wrote:
  Albin,
 
  What part are you looking to work on? I think there are a few new
 features being worked on for the current version, and Hopefully we are
 going to start ramping up on the qt port again soon.
 
  -- Seth
 
  Sent from my iPhone
 
  On Jul 30, 2015, at 11:11 AM, Albin Stigö albin.st...@gmail.com
 wrote:
 
  Hi,
 
  Is there a separate list for gnuradio-companion development? I'm
  interested in taking part...
 
  --Albin
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

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

Re: [Discuss-gnuradio] gnuradio-companion development

[Seth Hitefield]

Albin,

What part are you looking to work on? I think there are a few new features 
being worked on for the current version, and Hopefully we are going to start 
ramping up on the qt port again soon.

-- Seth

Sent from my iPhone

 On Jul 30, 2015, at 11:11 AM, Albin Stigö albin.st...@gmail.com wrote:
 
 Hi,
 
 Is there a separate list for gnuradio-companion development? I'm
 interested in taking part...
 
 --Albin
 
 ___
 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] gnuradio-companion development

[Albin Stigö]

Hi Seth,

I'm fairly new to gnuradio but I've spent the last couple of weeks
digging through the code of the runtime and grc. GRC doesn't work that
well on my macbook because of issues with qt and gtk2 (especially
hidpi retina displays)...

I suspect there are very few gnuradio users on mac but I became
interested in writing a Cocoa port of grc, if only for learning more
about SDR (this is a hobby for me). Cocoa is very well suited for
writing these kinds of visual applications (unfortunately they are not
really portable, or very limited so, using gnustep)

A QT port sounds really interesting as the model layer could be
separated and reused in a Cocoa app.

It would also be really neat if it was possible to test the flow graph
directly/dynamically without using python (dynamically build it in gcc
using the c++ api, perhaps in a separate process)... Although I
realize this is a much larger undertaking.

I recently found this and thought it was quite inspiring (web app):
http://www.pjrc.com/teensy/gui/

--Albin

On Thu, Jul 30, 2015 at 6:04 PM, Seth Hitefield sd...@vt.edu wrote:
 Albin,

 What part are you looking to work on? I think there are a few new features 
 being worked on for the current version, and Hopefully we are going to start 
 ramping up on the qt port again soon.

 -- Seth

 Sent from my iPhone

 On Jul 30, 2015, at 11:11 AM, Albin Stigö albin.st...@gmail.com wrote:

 Hi,

 Is there a separate list for gnuradio-companion development? I'm
 interested in taking part...

 --Albin

 ___
 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] gnuradio-companion-3.7.7.1 debian package

[Murray Thomson]

Hi Marcus,

I used a new installation of 12.04. I got the sources for 3.7.7.1 instead
of 3.7.7 this time. The generated debian package works fine.
My previous environment could have been wrong or maybe it was something in
3.7.7.
In any case, thanks a lot for your help.

Cheers,
Murray

2015-06-19 16:36 GMT+01:00 Marcus Müller marcus.muel...@ettus.com:

  Hi Murray,

 that's strange:

  ImportError: libboost_system.so.1.58.0: cannot open shared object file:
 No such file or directory

 contradicts

 libboost_system.so.1.48.0 = /usr/lib/libboost_system.so.1.48.0
 (0xb71d8000)


 There's something seriously wrong about this situation. If not
 gnuradio-config-info was linked against boost 1.58 symbols, then one of the
 libraries it tries to use one your second PC is. That error comes from
 *somewhere*. Maybe you'd want to compare the ldd $(...) output of both
 systems, especially the individual paths of the libraries. Did you happen
 to build a custom boost on the second machine at some point?

 Best regards,
 Marcus


 On 06/19/2015 05:27 PM, Murray Thomson wrote:

 Hello again

 2015-06-19 14:35 GMT+01:00 Marcus Müller marcus.muel...@ettus.com:

  Hi!

 user@pc:~$ gnuradio-config-info
  ImportError: libboost_system.so.1.58.0: cannot open shared object file:
 No such file or directory


  This means that the gnuradio-config-info was definitely built with
 another version of boost (1.58) than what is found at the moment you start
 it.

 This is what I thought too but  sudo find / -name libboost* only finds
 libraries for boost 1.46 and 1.48.

   The point about distributions is that they strive to keep all their
 libraries coherent in one release. So, although the install script might
 have installed the modern boost version correctly and set up some paths so
 that on your first PC, linux knows where to look for boost 1.58, on the
 other, this won't work automatically.
 You can find out where the libboost_system.so.1.58.0 is on the system
 where it works by running ldd $(which gnuradio-config-info).

  The system works but win a Gnuradio installed from the build_gnuradio
 script, not the debian package that I built.
 user@pc:~$ ldd $(which gnuradio-config-info)
 linux-gate.so.1 =  (0xb776)
 libgnuradio-runtime-3.7.8git.so.0.0.0 =
 /usr/local/lib/libgnuradio-runtime-3.7.8git.so.0.0.0 (0xb7671000)
 libboost_program_options.so.1.48.0 =
 /usr/lib/libboost_program_options.so.1.48.0 (0xb7612000)
 libpthread.so.0 = /lib/i386-linux-gnu/libpthread.so.0 (0xb75f6000)
 libstdc++.so.6 = /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7511000)
 libgcc_s.so.1 = /lib/i386-linux-gnu/libgcc_s.so.1 (0xb74f3000)
 libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xb7349000)
 libgnuradio-pmt-3.7.8git.so.0.0.0 =
 /usr/local/lib/libgnuradio-pmt-3.7.8git.so.0.0.0 (0xb730b000)
 libvolk.so.1.0 = /usr/local/lib/libvolk.so.1.0 (0xb71fa000)
 libboost_filesystem.so.1.48.0 =
 /usr/lib/libboost_filesystem.so.1.48.0 (0xb71dc000)
 libboost_system.so.1.48.0 = /usr/lib/libboost_system.so.1.48.0
 (0xb71d8000)
 libboost_thread.so.1.48.0 = /usr/lib/libboost_thread.so.1.48.0
 (0xb71bf000)
 librt.so.1 = /lib/i386-linux-gnu/librt.so.1 (0xb71b6000)
 libm.so.6 = /lib/i386-linux-gnu/libm.so.6 (0xb7189000)
 /lib/ld-linux.so.2 (0xb7761000)
 liborc-0.4.so.0 = /usr/lib/i386-linux-gnu/liborc-0.4.so.0 (0xb70f9000)


 So the question is: which tool did you exactly use to install GNU Radio?

 I used cmake with the following parameters:
 cmake -DCMAKE_INSTALL_PREFIX=/usr SYSCONFDIR=/etc
 -DENABLE_STATIC_LIBS=False \
 -DENABLE_DOXYGEN=False -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF \
 -DENABLE_GR_DTV=OFF -DENABLE_GR_ATSC=OFF ..


  If you use pyBOMBS, you get the ability to install everything, including
 updated versions of boost etc., into a specific private directory, and
 generate a script that sets up all paths accordingly. You can then just
 copy that prefix and script over to the other PC; that's pretty
 distribution agnostic, but to be honest: If you wanted to make packages for
 all the things that GNU Radio likes to have a bit more recent, you'd be
 basically producing packages for half the development libraries that GNU
 Radio needs -- 12.04 is 3 years old...

 I wish I could upgrade my Ubuntu but I'm stack with 12.04 for other
 reasons. I'll try the pybombs way and also the same method for gnuradio
 3.7.5 to check that I get the same error



 Best regards,
 Marcus


  Thank you for your help
  Murray


 On 06/19/2015 02:52 PM, Murray Thomson wrote:

   Thanks for that Marcus, I got around that first step.

 My computer runs Ubuntu 12.04 with libboost 1.48 and it has a working
 gnuradio installation v3.7.7.1-120-g67463e74 from the script in the web.
 I used that computer to create the debian package based on
 https://github.com/gnuradio/gnuradio.git tag v3.7.7 and I installed it
 in another Ubuntu 12.04 with libboost 1.48.
  get the following error message when running this command or any 

Re: [Discuss-gnuradio] gnuradio-companion-3.7.7.1 debian package

[Marcus Müller]

Hi!
 user@pc:~$ gnuradio-config-info
 ImportError: libboost_system.so.1.58.0: cannot open shared object
 file: No such file or directory

This means that the gnuradio-config-info was definitely built with
another version of boost (1.58) than what is found at the moment you
start it.
The point about distributions is that they strive to keep all their
libraries coherent in one release. So, although the install script might
have installed the modern boost version correctly and set up some paths
so that on your first PC, linux knows where to look for boost 1.58, on
the other, this won't work automatically.
You can find out where the libboost_system.so.1.58.0 is on the system
where it works by running ldd $(which gnuradio-config-info).

So the question is: which tool did you exactly use to install GNU Radio?

If you use pyBOMBS, you get the ability to install everything, including
updated versions of boost etc., into a specific private directory, and
generate a script that sets up all paths accordingly. You can then just
copy that prefix and script over to the other PC; that's pretty
distribution agnostic, but to be honest: If you wanted to make packages
for all the things that GNU Radio likes to have a bit more recent, you'd
be basically producing packages for half the development libraries that
GNU Radio needs -- 12.04 is 3 years old...

Best regards,
Marcus

On 06/19/2015 02:52 PM, Murray Thomson wrote:
 Thanks for that Marcus, I got around that first step.

 My computer runs Ubuntu 12.04 with libboost 1.48 and it has a working
 gnuradio installation v3.7.7.1-120-g67463e74 from the script in the web.
 I used that computer to create the debian package based on
 https://github.com/gnuradio/gnuradio.git tag v3.7.7 and I installed it
 in another Ubuntu 12.04 with libboost 1.48.
  get the following error message when running this command or any
 simple gnuradio script:

 user@pc:~$ gnuradio-config-info
 ImportError: libboost_system.so.1.58.0: cannot open shared object
 file: No such file or directory

 I first thought that 3.7.7 must depend on libboost 1.58 but it works
 well with 1.48 when I use the script to install it so, how did that
 dependency get there?

 My debian has installed files into the folders /etc, /usr/bin,
 /usr/lib, /usr/share, /usr/include and my control file depends on the
 following packages:

 Depends: libfftw3-3, libpulse0, python, python-numpy, python-gtk2,
 python-wxgtk2.8, python-qwt5-qt4, python-lxml, python-cheetah,
 python-qt4, python-qwt5-qt4, libpulse0, libasound2, alsa-base,
 libboost-program-options1.48.0, libboost-filesystem1.48.0,
 libboost-thread1.48.0, libqtcore4, libsdl1.2debian, libgsl0ldbl,
 liborc-0.4-0, libusb-1.0-0, sdcc

 I'm using

 PATH = /usr/bin
 LD_LIBRARY = /usr/lib
 PYTHONPATH =
 /usr/lib/python2.7/site-packages/:/usr/lib/python2.7/:/usr/lib/python2.7/dist-packages
 PKG_CONFIG_PATH = /usr/lib/pkgconfig

 Could someone point me in the right direction please?

 Cheers,
 Murray

 2015-06-19 10:42 GMT+01:00 Marcus Müller marcus.muel...@ettus.com
 mailto:marcus.muel...@ettus.com:

 Hi Murray,

 you'd typically do something like:

 cmake -DCMAKE_INSTALL_PREFIX=/usr ..

 to match what debian expects.
 Then, instead of simply installing stuff there, you install into
 your fake root directory using
 make
 make install DESTDIR=/home/murray/fake_root/whatever

 That will only bend around the paths where files are copied to,
 not the paths contained in the files themselves

 Best regards,
 Marcus


 On 06/19/2015 11:06 AM, Murray Thomson wrote:
 Hi,

 I need a GnuRadio debian package for version 3.7.7.1 to be
 installed in many different computers. I've tried creating it
 myself but I run into many difficulties. For example the command
 gnuradio-config-info --prefix --prefsdir --sysconfdir was
 pointing to the folder where I created the debian.

 I found a package for Arch linux in
 https://www.archlinux.org/packages/community/x86_64/gnuradio/
 And I was going to try to convert it to a debian. Before I do
 that. Is there a repo where I can find this? Ideally
 gnuradio-companion (including gnuradio) version 3.7.7.1 for both
 x86_64 and i636 debian package that will be installed in an
 Ubuntu 12.04 system.

 Thanks a lot,
 Murray


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


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org mailto: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] gnuradio-companion-3.7.7.1 debian package

[Murray Thomson]

Thanks for that Marcus, I got around that first step.

My computer runs Ubuntu 12.04 with libboost 1.48 and it has a working
gnuradio installation v3.7.7.1-120-g67463e74 from the script in the web.
I used that computer to create the debian package based on
https://github.com/gnuradio/gnuradio.git tag v3.7.7 and I installed it in
another Ubuntu 12.04 with libboost 1.48.
 get the following error message when running this command or any simple
gnuradio script:

user@pc:~$ gnuradio-config-info
ImportError: libboost_system.so.1.58.0: cannot open shared object file: No
such file or directory

I first thought that 3.7.7 must depend on libboost 1.58 but it works well
with 1.48 when I use the script to install it so, how did that dependency
get there?

My debian has installed files into the folders /etc, /usr/bin, /usr/lib,
/usr/share, /usr/include and my control file depends on the following
packages:

Depends: libfftw3-3, libpulse0, python, python-numpy, python-gtk2,
python-wxgtk2.8, python-qwt5-qt4, python-lxml, python-cheetah, python-qt4,
python-qwt5-qt4, libpulse0, libasound2, alsa-base,
libboost-program-options1.48.0, libboost-filesystem1.48.0,
libboost-thread1.48.0, libqtcore4, libsdl1.2debian, libgsl0ldbl,
liborc-0.4-0, libusb-1.0-0, sdcc

I'm using

PATH = /usr/bin
LD_LIBRARY = /usr/lib
PYTHONPATH =
/usr/lib/python2.7/site-packages/:/usr/lib/python2.7/:/usr/lib/python2.7/dist-packages
PKG_CONFIG_PATH = /usr/lib/pkgconfig

Could someone point me in the right direction please?

Cheers,
Murray

2015-06-19 10:42 GMT+01:00 Marcus Müller marcus.muel...@ettus.com:

  Hi Murray,

 you'd typically do something like:

 cmake -DCMAKE_INSTALL_PREFIX=/usr ..

 to match what debian expects.
 Then, instead of simply installing stuff there, you install into your fake
 root directory using
 make
 make install DESTDIR=/home/murray/fake_root/whatever

 That will only bend around the paths where files are copied to, not the
 paths contained in the files themselves

 Best regards,
 Marcus


 On 06/19/2015 11:06 AM, Murray Thomson wrote:

   Hi,

  I need a GnuRadio debian package for version 3.7.7.1 to be installed in
 many different computers. I've tried creating it myself but I run into many
 difficulties. For example the command gnuradio-config-info --prefix
 --prefsdir --sysconfdir was pointing to the folder where I created the
 debian.

 I found a package for Arch linux in
 https://www.archlinux.org/packages/community/x86_64/gnuradio/
  And I was going to try to convert it to a debian. Before I do that. Is
 there a repo where I can find this? Ideally gnuradio-companion (including
 gnuradio) version 3.7.7.1 for both x86_64 and i636 debian package that will
 be installed in an Ubuntu 12.04 system.

  Thanks a lot,
  Murray


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



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


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

Re: [Discuss-gnuradio] gnuradio-companion-3.7.7.1 debian package

[Marcus Müller]

Hi Murray,

you'd typically do something like:

cmake -DCMAKE_INSTALL_PREFIX=/usr ..

to match what debian expects.
Then, instead of simply installing stuff there, you install into your
fake root directory using
make
make install DESTDIR=/home/murray/fake_root/whatever

That will only bend around the paths where files are copied to, not the
paths contained in the files themselves

Best regards,
Marcus

On 06/19/2015 11:06 AM, Murray Thomson wrote:
 Hi,

 I need a GnuRadio debian package for version 3.7.7.1 to be installed
 in many different computers. I've tried creating it myself but I run
 into many difficulties. For example the command gnuradio-config-info
 --prefix --prefsdir --sysconfdir was pointing to the folder where I
 created the debian.

 I found a package for Arch linux in
 https://www.archlinux.org/packages/community/x86_64/gnuradio/
 And I was going to try to convert it to a debian. Before I do that. Is
 there a repo where I can find this? Ideally gnuradio-companion
 (including gnuradio) version 3.7.7.1 for both x86_64 and i636 debian
 package that will be installed in an Ubuntu 12.04 system.

 Thanks a lot,
 Murray


 ___
 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] gnuradio-companion-3.7.7.1 debian package

[Murray Thomson]

Hello again

2015-06-19 14:35 GMT+01:00 Marcus Müller marcus.muel...@ettus.com:

  Hi!

 user@pc:~$ gnuradio-config-info
  ImportError: libboost_system.so.1.58.0: cannot open shared object file:
 No such file or directory


 This means that the gnuradio-config-info was definitely built with another
 version of boost (1.58) than what is found at the moment you start it.

This is what I thought too but  sudo find / -name libboost* only finds
libraries for boost 1.46 and 1.48.

The point about distributions is that they strive to keep all their
 libraries coherent in one release. So, although the install script might
 have installed the modern boost version correctly and set up some paths so
 that on your first PC, linux knows where to look for boost 1.58, on the
 other, this won't work automatically.
 You can find out where the libboost_system.so.1.58.0 is on the system
 where it works by running ldd $(which gnuradio-config-info).

The system works but win a Gnuradio installed from the build_gnuradio
script, not the debian package that I built.
user@pc:~$ ldd $(which gnuradio-config-info)
linux-gate.so.1 =  (0xb776)
libgnuradio-runtime-3.7.8git.so.0.0.0 =
/usr/local/lib/libgnuradio-runtime-3.7.8git.so.0.0.0 (0xb7671000)
libboost_program_options.so.1.48.0 =
/usr/lib/libboost_program_options.so.1.48.0 (0xb7612000)
libpthread.so.0 = /lib/i386-linux-gnu/libpthread.so.0 (0xb75f6000)
libstdc++.so.6 = /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7511000)
libgcc_s.so.1 = /lib/i386-linux-gnu/libgcc_s.so.1 (0xb74f3000)
libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xb7349000)
libgnuradio-pmt-3.7.8git.so.0.0.0 =
/usr/local/lib/libgnuradio-pmt-3.7.8git.so.0.0.0 (0xb730b000)
libvolk.so.1.0 = /usr/local/lib/libvolk.so.1.0 (0xb71fa000)
libboost_filesystem.so.1.48.0 = /usr/lib/libboost_filesystem.so.1.48.0
(0xb71dc000)
libboost_system.so.1.48.0 = /usr/lib/libboost_system.so.1.48.0
(0xb71d8000)
libboost_thread.so.1.48.0 = /usr/lib/libboost_thread.so.1.48.0
(0xb71bf000)
librt.so.1 = /lib/i386-linux-gnu/librt.so.1 (0xb71b6000)
libm.so.6 = /lib/i386-linux-gnu/libm.so.6 (0xb7189000)
/lib/ld-linux.so.2 (0xb7761000)
liborc-0.4.so.0 = /usr/lib/i386-linux-gnu/liborc-0.4.so.0 (0xb70f9000)


 So the question is: which tool did you exactly use to install GNU Radio?

I used cmake with the following parameters:
cmake -DCMAKE_INSTALL_PREFIX=/usr SYSCONFDIR=/etc
-DENABLE_STATIC_LIBS=False \
-DENABLE_DOXYGEN=False -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF \
-DENABLE_GR_DTV=OFF -DENABLE_GR_ATSC=OFF ..


 If you use pyBOMBS, you get the ability to install everything, including
 updated versions of boost etc., into a specific private directory, and
 generate a script that sets up all paths accordingly. You can then just
 copy that prefix and script over to the other PC; that's pretty
 distribution agnostic, but to be honest: If you wanted to make packages for
 all the things that GNU Radio likes to have a bit more recent, you'd be
 basically producing packages for half the development libraries that GNU
 Radio needs -- 12.04 is 3 years old...

I wish I could upgrade my Ubuntu but I'm stack with 12.04 for other
reasons. I'll try the pybombs way and also the same method for gnuradio
3.7.5 to check that I get the same error



 Best regards,
 Marcus


Thank you for your help
Murray


 On 06/19/2015 02:52 PM, Murray Thomson wrote:

   Thanks for that Marcus, I got around that first step.

 My computer runs Ubuntu 12.04 with libboost 1.48 and it has a working
 gnuradio installation v3.7.7.1-120-g67463e74 from the script in the web.
 I used that computer to create the debian package based on
 https://github.com/gnuradio/gnuradio.git tag v3.7.7 and I installed it in
 another Ubuntu 12.04 with libboost 1.48.
  get the following error message when running this command or any simple
 gnuradio script:

  user@pc:~$ gnuradio-config-info
  ImportError: libboost_system.so.1.58.0: cannot open shared object file:
 No such file or directory

  I first thought that 3.7.7 must depend on libboost 1.58 but it works well
 with 1.48 when I use the script to install it so, how did that dependency
 get there?

 My debian has installed files into the folders /etc, /usr/bin, /usr/lib,
 /usr/share, /usr/include and my control file depends on the following
 packages:

 Depends: libfftw3-3, libpulse0, python, python-numpy, python-gtk2,
 python-wxgtk2.8, python-qwt5-qt4, python-lxml, python-cheetah, python-qt4,
 python-qwt5-qt4, libpulse0, libasound2, alsa-base,
 libboost-program-options1.48.0, libboost-filesystem1.48.0,
 libboost-thread1.48.0, libqtcore4, libsdl1.2debian, libgsl0ldbl,
 liborc-0.4-0, libusb-1.0-0, sdcc

  I'm using

  PATH = /usr/bin
  LD_LIBRARY = /usr/lib
  PYTHONPATH =
 /usr/lib/python2.7/site-packages/:/usr/lib/python2.7/:/usr/lib/python2.7/dist-packages
  PKG_CONFIG_PATH = /usr/lib/pkgconfig

 Could someone point me in the right direction please?

 Cheers,
  Murray

 2015-06-19 10:42 

Re: [Discuss-gnuradio] gnuradio-companion-3.7.7.1 debian package

[Marcus Müller]

Hi Murray,

that's strange:

 ImportError: libboost_system.so.1.58.0: cannot open shared object
file: No such file or directory

contradicts
 libboost_system.so.1.48.0 = /usr/lib/libboost_system.so.1.48.0
 (0xb71d8000)

There's something seriously wrong about this situation. If not
gnuradio-config-info was linked against boost 1.58 symbols, then one of
the libraries it tries to use one your second PC is. That error comes
from /somewhere/. Maybe you'd want to compare the ldd $(...) output of
both systems, especially the individual paths of the libraries. Did you
happen to build a custom boost on the second machine at some point?

Best regards,
Marcus

On 06/19/2015 05:27 PM, Murray Thomson wrote:
 Hello again

 2015-06-19 14:35 GMT+01:00 Marcus Müller marcus.muel...@ettus.com
 mailto:marcus.muel...@ettus.com:

 Hi!
 user@pc:~$ gnuradio-config-info
 ImportError: libboost_system.so.1.58.0: cannot open shared object
 file: No such file or directory

 This means that the gnuradio-config-info was definitely built with
 another version of boost (1.58) than what is found at the moment
 you start it.

 This is what I thought too but  sudo find / -name libboost* only
 finds libraries for boost 1.46 and 1.48.

 The point about distributions is that they strive to keep all
 their libraries coherent in one release. So, although the install
 script might have installed the modern boost version correctly and
 set up some paths so that on your first PC, linux knows where to
 look for boost 1.58, on the other, this won't work automatically.
 You can find out where the libboost_system.so.1.58.0 is on the
 system where it works by running ldd $(which gnuradio-config-info).

 The system works but win a Gnuradio installed from the build_gnuradio
 script, not the debian package that I built.
 user@pc:~$ ldd $(which gnuradio-config-info)
 linux-gate.so.1 =  (0xb776)
 libgnuradio-runtime-3.7.8git.so.0.0.0 =
 /usr/local/lib/libgnuradio-runtime-3.7.8git.so.0.0.0 (0xb7671000)
 libboost_program_options.so.1.48.0 =
 /usr/lib/libboost_program_options.so.1.48.0 (0xb7612000)
 libpthread.so.0 = /lib/i386-linux-gnu/libpthread.so.0 (0xb75f6000)
 libstdc++.so.6 = /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7511000)
 libgcc_s.so.1 = /lib/i386-linux-gnu/libgcc_s.so.1 (0xb74f3000)
 libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xb7349000)
 libgnuradio-pmt-3.7.8git.so.0.0.0 =
 /usr/local/lib/libgnuradio-pmt-3.7.8git.so.0.0.0 (0xb730b000)
 libvolk.so.1.0 = /usr/local/lib/libvolk.so.1.0 (0xb71fa000)
 libboost_filesystem.so.1.48.0 =
 /usr/lib/libboost_filesystem.so.1.48.0 (0xb71dc000)
 libboost_system.so.1.48.0 = /usr/lib/libboost_system.so.1.48.0
 (0xb71d8000)
 libboost_thread.so.1.48.0 = /usr/lib/libboost_thread.so.1.48.0
 (0xb71bf000)
 librt.so.1 = /lib/i386-linux-gnu/librt.so.1 (0xb71b6000)
 libm.so.6 = /lib/i386-linux-gnu/libm.so.6 (0xb7189000)
 /lib/ld-linux.so.2 (0xb7761000)
 liborc-0.4.so.0 = /usr/lib/i386-linux-gnu/liborc-0.4.so.0
 (0xb70f9000)


 So the question is: which tool did you exactly use to install GNU
 Radio?

 I used cmake with the following parameters:
 cmake -DCMAKE_INSTALL_PREFIX=/usr SYSCONFDIR=/etc
 -DENABLE_STATIC_LIBS=False \
 -DENABLE_DOXYGEN=False -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF \
 -DENABLE_GR_DTV=OFF -DENABLE_GR_ATSC=OFF ..
  

 If you use pyBOMBS, you get the ability to install everything,
 including updated versions of boost etc., into a specific private
 directory, and generate a script that sets up all paths
 accordingly. You can then just copy that prefix and script over to
 the other PC; that's pretty distribution agnostic, but to be
 honest: If you wanted to make packages for all the things that GNU
 Radio likes to have a bit more recent, you'd be basically
 producing packages for half the development libraries that GNU
 Radio needs -- 12.04 is 3 years old...

 I wish I could upgrade my Ubuntu but I'm stack with 12.04 for other
 reasons. I'll try the pybombs way and also the same method for
 gnuradio 3.7.5 to check that I get the same error
  


 Best regards,
 Marcus


 Thank you for your help
 Murray


 On 06/19/2015 02:52 PM, Murray Thomson wrote:
 Thanks for that Marcus, I got around that first step.

 My computer runs Ubuntu 12.04 with libboost 1.48 and it has a
 working gnuradio installation v3.7.7.1-120-g67463e74 from the
 script in the web.
 I used that computer to create the debian package based on
 https://github.com/gnuradio/gnuradio.git tag v3.7.7 and I
 installed it in another Ubuntu 12.04 with libboost 1.48.
  get the following error message when running this command or any
 simple gnuradio script:

 user@pc:~$ gnuradio-config-info
 ImportError: libboost_system.so.1.58.0: cannot open shared object
 file: No such file or directory

 I first thought that 3.7.7 

Re: [Discuss-gnuradio] gnuradio-companion and multithreading

[Marcus Müller]

Hi Andreas,

 If i stop the drawing of all the graphs in the compiled GNU Radio
application, i could change parameters like the volume or gain with the
sliders/text boxes now.
That was to be expected :) Calculating a 512-point FFT is somewhat
ressource-consuming, but drawing and updating a graph on a display is
much worse...

 The next was to decrease the sample rate of some blocks by adjusting
 the decimation.
Indeed! No matter what kind of processing you do, it generally scales
linearly with the samples per second you need to process...

 I could not reduce the sample rate of the RTL block below 1 Msample.
 The testing tool told me that sample rates below 1M are invalid for
 the RTL stick. So i think the RTL source block needs the most CPU time.
No, not necessarily. It just means that the RTL stick won't produce
samples at a lower rate than 1MS/s. Nothing you can do about that --
decimation from there on has to happen in software.

 All this changes reduced the overruns a lot. The CPU load decreases
 about 20 % to about 170 %.
This is a classical problem of engineering: You have to do something
with a given complexity, but your job is to use as little ressources as
possible.
Therefore, the first step you need to perform in your signal flow would
be decimation to the minimum viable sampling rate, which of course
depends on your signal and application.

 This application works in general.
 To be honest, I generally consider the Raspberry Pi and similar devices
 to be embedded ones with hardware that underwent optimization for
 exactly this application -- low cost embedded media playing linux GPIO
 bitbanging computing. Not general purpose GUIs like the GRC.

 Generally, the most sensible approach to using such devices with GRC I'd
 say is to run GRC on your real PC, and transfer over the resulting
 python program to your embedded device. Please don't expect wonders from
 the signal processing performance of a dual core ARM processor --
 there's only so much FLOPS you can get out of silicon...
 Ok, and which processors do you suggest in general for signal
 processing ? Which processors are optimized for signal processing ?
Um, that's a broad question. There's people doing Signal Processing on
huge clusters of blade computers, and there's people that do signal
processing inside your run-off-the-mill hearing aid. Of course, there's
different things you can achieve, and different amounts of flexibility
and design effort...

However, you never can have too much processing power. Generally,
since you're using an RTL dongle, you can just design your application
on your PC, make it work there. Then, analyze how much power it *needs*,
as in an estimate of operations per second. After that, you'll get a
feeling for which class of device you'll need. The tricky part here is
that different architectures have different efficiencies when doing
things, and there's a different set of optimizations for different
architectures. In essence: if your application uses 50% of the power
your quadcore i7 has, there's no way you'll just run the same
application on your mobile phone...

Greetings,
Marcus

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

Re: [Discuss-gnuradio] gnuradio-companion and multithreading

[Andreas Ladanyi]

Hi Marcus,

Hi Andreas,

GRC is already as multithreaded as GTK applications can generally be --
I think the bottleneck here is really your Bananapi's CPU, its RAM and
its graphics card driver.
If i stop the drawing of all the graphs in the compiled GNU Radio 
application, i could change parameters like the volume or gain with the 
sliders/text boxes now.


The next was to decrease the sample rate of some blocks by adjusting the 
decimation.


I could not reduce the sample rate of the RTL block below 1 Msample. The 
testing tool told me that sample rates below 1M are invalid for the RTL 
stick. So i think the RTL source block needs the most CPU time.


All this changes reduced the overruns a lot. The CPU load decreases 
about 20 % to about 170 %.


This application works in general.

To be honest, I generally consider the Raspberry Pi and similar devices
to be embedded ones with hardware that underwent optimization for
exactly this application -- low cost embedded media playing linux GPIO
bitbanging computing. Not general purpose GUIs like the GRC.

Generally, the most sensible approach to using such devices with GRC I'd
say is to run GRC on your real PC, and transfer over the resulting
python program to your embedded device. Please don't expect wonders from
the signal processing performance of a dual core ARM processor --
there's only so much FLOPS you can get out of silicon...
Ok, and which processors do you suggest in general for signal processing 
? Which processors are optimized for signal processing ?


Best regards,
Marcus

regards,
Andreas



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

Re: [Discuss-gnuradio] gnuradio-companion and multithreading

[Marcus Müller]

Hi Andreas,

GRC is already as multithreaded as GTK applications can generally be --
I think the bottleneck here is really your Bananapi's CPU, its RAM and
its graphics card driver.
To be honest, I generally consider the Raspberry Pi and similar devices
to be embedded ones with hardware that underwent optimization for
exactly this application -- low cost embedded media playing linux GPIO
bitbanging computing. Not general purpose GUIs like the GRC.

Generally, the most sensible approach to using such devices with GRC I'd
say is to run GRC on your real PC, and transfer over the resulting
python program to your embedded device. Please don't expect wonders from
the signal processing performance of a dual core ARM processor --
there's only so much FLOPS you can get out of silicon...

Best regards,
Marcus

On 01/21/2015 04:47 PM, Andreas Ladanyi wrote:
 Hi,

 iam testing gnuradio-companion editor on the Bananapi LUbuntu. When i
 am editing a block or drawing a block i recognize in top that the
 python process has a 100% CPU (i have 2 CPUs) load. The
 gnuradio-companion editor reacts very slow.

 Is it possible to tell the editor or python to use 2 CPUs ? I could
 remember that each gnuradio block in a project is one thread when
 running an compiled grc project so it seems to possible in general.

 Andreas

 ___
 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] gnuradio-companion and multithreading

[mleech]

 

That would require wholesale reworking of GRC. 

You *really, really, really* shouldn't think of a lowly banana-pi as
your *development* environment. The .py files that are generated by GRC
can be generated on a real machine, and executed on the banana-pi,
provided that you have identical GR installs on both sides. 

On 2015-01-21 10:47, Andreas Ladanyi wrote: 

 Hi,
 
 iam testing gnuradio-companion editor on the Bananapi LUbuntu. When i am 
 editing a block or drawing a block i recognize in top that the python process 
 has a 100% CPU (i have 2 CPUs) load. The gnuradio-companion editor reacts 
 very slow.
 
 Is it possible to tell the editor or python to use 2 CPUs ? I could remember 
 that each gnuradio block in a project is one thread when running an compiled 
 grc project so it seems to possible in general.
 
 Andreas
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] Gnuradio Companion Blocks missing property tabs

[Tom Rondeau]

On Thu, Aug 7, 2014 at 5:41 PM, Richard Bell richard.be...@gmail.com
wrote:

 Hello all,

 I noticed today that, for example, my 'QT GUI Time Sink' blocks properties
 window is missing the config tab. This means I cannot change the label of
 my time sink plots. In general, all of my grc blocks have no tabs, only the
 main parameters window.

 I'm using ubuntu 13.10 with gnuradio 3.7.3, installed using the
 master/unstable commands from the ettus research website.
 http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Linux

 Has anyone experienced something like this before? If so, what was the fix?

 Thanks,
 Rich



Hi Rich,

The tab feature was introduced in 3.7.4, so if you need them, you'll have
to update. You can see all of the new features in that version here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_7_4

Note that you can middle-mouse click on the graph to get a menu that will
allow you to change the labels and other features while the graph is
running.

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

Re: [Discuss-gnuradio] gnuradio companion core dump

[Martin Braun]

These can be a bit annoying. You can inspect the core dump
(http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsDebugging)
to see where this happens. Chances are you rebuilt GNU Radio and this is
some OOT module that is acting up.

M

On 08/04/2014 12:14 AM, Tom McDermott wrote:
 I had this problem a couple weeks ago.  After deleting the build
 subdirectory and rebuilding it went away until today
 when it came back.  I deleted the build directory and
 re-cmake/make/install/ldconfig, but the problem will not clear.
 
 
 gnuradio-companion
 linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.007.001-84-gd99ce4ef
 
 terminate called after throwing an instance of 'std::runtime_error'
   what():  rpcmanager: Aggregator not in use, and a rpc booter is
 already registered
 
 Aborted (core dumped)
 
 
 Ubuntu 14.04
 Gnuradio master  41d0844
 
 -- Tom, N5EG
 
 
 
 ___
 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] gnuradio-companion segfaults with latest gnuradio master and gr-osmosdr

[Tom Rondeau]

On Thu, Dec 19, 2013 at 1:50 PM, Nowlan, Sean
sean.now...@gtri.gatech.edu wrote:
 When I run gnuradio-companion with the latest gnuradio master and gr-osmosdr
 master, it segfaults. A backtrace reveals that there’s a problem when Python
 tries to load _osmosdr_swig. If I uninstall gr-osmosdr, gnuradio-companion
 opens normally.

I just tried this with the latest git checkouts of everything
(gnuradio, osmosdr, hackrf, rtlsdr, gr-omosdr). Here's the enabled
stuff in my gr-osmosdr:

-- ##
-- # gr-osmosdr enabled components
-- ##
--   * Python support
--   * sysmocom OsmoSDR
--   * FUNcube Dongle
--   * IQ File Source
--   * Osmocom RTLSDR
--   * RTLSDR TCP Client
--   * Ettus USRP Devices
--   * HackRF Jawbreaker
--   * RFSPACE NetSDR
-- 
-- ##
-- # gr-osmosdr disabled components
-- ##
--   * Osmocom IQ Imbalance Correction
--   * FUNcube Dongle Pro+
--   * Osmocom MiriSDR
--   * nuand bladeRF


Everything runs fine for me with this setup.

Tom

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

Re: [Discuss-gnuradio] GNURadio Companion PAUSE

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Paul,

couldn't let that comment sit around long.

Though, if I put two and two togehter, I'd say since you've been
asking what error 28 indicates, it has even nothing much to do with
computing capabilities of your computer. Just a shortage of
sufficiently fast storage.
As an complacent linux user, by the way, I'd assume that you'll be off
as good as with a RAM disk enlarging your filesystem write buffers,
without running into system errors (28). That would most probably
re-introduce overruns, though. But that's how it is -- just get some
RAM, and record not more data than fits in there; or get a fast
storage system that can take the 8 bytes per sample.

Please, try to solve one problem with us at a time, I'm starting to
feel that discuss-gnuradio is doing your dev job.

Greetings, and happy hacking
Marcus

On 06.12.2013 07:27, Marcus Müller wrote:
 Well, this is just guessing in the blue, but: It might be the
 computing capability of your computer. Not necessarily of
 yourself. :D SCNR, Greetings, Marcus
 
 On 05.12.2013 22:22, Paul B. Huter wrote:
 How do I resolve this problem, then? Is it an issue with my 
 computing capability?
 
 
 On Thu, Dec 5, 2013 at 3:13 PM, Nick Foster
 bistrom...@gmail.com wrote:
 
 Again, Volk has nothing to do with it. All that printout means
 is that your flowgraph is now using a block which uses a Volk 
 function for acceleration. It has nothing to do with the
 problem you're seeing.
 
 --n
 
 
 On Thu, Dec 5, 2013 at 1:11 PM, Paul B. Huter 
 paul.b.hu...@gmail.comwrote:
 
 Thanks! Got that working with a valve and a button. However,
 my flow now uses Volk machine, again, which doesn't record my
 data as well as it was recording before the valve (and
 without Volk machine). Any way to keep it from doing this?
 
 Paul B. Huter On Dec 5, 2013 11:11 AM, Marcus Müller 
 mar...@hostalia.de wrote:
 
 Hi Paul, use a valve together with some input widget.
 
 There has been great discussion over how to build a valve system 
 the last month, you might need to read multiple threads to find 
 the solution that suits you best.
 
 Greetings, Marcus
 
 
 On 05.12.2013 17:07, Paul B. Huter wrote:
 Is there a way to make GNURadio pause before
 recording, and wait for the user to start things? It
 takes a few seconds for my flow to start up, and I
 would like to have control over the precise time it
 starts recording. For example, I would run the flow,
 but the record would wait until I clicked or pressed a
 key.
 
 Paul B. Huter
 
 
 
 ___ 
 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
 
 
 
 
 
 ___ Discuss-gnuradio
 mailing list Discuss-gnuradio@gnu.org 
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSoXmEAAoJEAFxB7BbsDrLe2QIAJRYz64jZRUB4QkwgdQ3eEHM
PBQ/yZ8TNCXtKopoOAay7zsSUlm+Eof7QDZOx/uQanYzHtkcB9jIDa3ZkeSkKXnM
n/WuXAZB7xf7Tu7P1ELWJqBy4Da3vt0z7eh68j/03UbudNCHprIE7cH3ws3/hMF1
k3r10qFB1A+hoxe8+GGWwcl19rB8OKUutuigTSn9E2r1NXKCkwYJkL+/41T27cOS
Tmi7zq9+L1No5wSFTpm+NGVQuRugKkgPYk1oSizzhK4+QFXlTWuC+4kCJi2LwoH2
0OSMuhpF+vrjIj12elKjSo/mrOIuQ/qzgfaVEffu9AXOnfIqZ19LIV8dM9ad7Bo=
=C7Pu
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] GNURadio Companion PAUSE

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Paul,
use a valve together with some input widget.

There has been great discussion over how to build a valve system the
last month, you might need to read multiple threads to find the
solution that suits you best.

Greetings,
Marcus


On 05.12.2013 17:07, Paul B. Huter wrote:
 Is there a way to make GNURadio pause before recording, and wait
 for the user to start things? It takes a few seconds for my flow to
 start up, and I would like to have control over the precise time it
 starts recording. For example, I would run the flow, but the record
 would wait until I clicked or pressed a key.
 
 Paul B. Huter
 
 
 
 ___ Discuss-gnuradio
 mailing list Discuss-gnuradio@gnu.org 
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSoLONAAoJEAFxB7BbsDrLCs0H/3qETPYomrCFTrbLi8IykbhQ
rQNKa+IAnfnE2TtjBcFX/hkAKKZGJbPKai0kM4S523+qjQnfdk4AJwc+3LAKWWoA
ATeSdBSZLUhh724MmGXd7Dg4acatbYfwvWxEA3TUQqesrpY2EX5bp5PuaoVDSMpr
SrNwzOn9DaCFj9cuJBkOFcHIJ4uzI5omzW5Kqjr2uMLdzlZiHvb5LGIsg0TsC/lK
XVWT4IY9KSO7dNKOyLm0hKQvVaavApmF337GfjxQPatN93Wx7bcktRHYlp74oRg5
hHZ2vtd+tlknFUlv58jraFsUNqhtxMFbrTomZhVzCL+odFkyzY0E+rINvVl9FgQ=
=rCw/
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] GNURadio Companion PAUSE

[Paul B. Huter]

Thanks! Got that working with a valve and a button. However, my flow now
uses Volk machine, again, which doesn't record my data as well as it was
recording before the valve (and without Volk machine). Any way to keep it
from doing this?

Paul B. Huter
On Dec 5, 2013 11:11 AM, Marcus Müller mar...@hostalia.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Paul,
 use a valve together with some input widget.

 There has been great discussion over how to build a valve system the
 last month, you might need to read multiple threads to find the
 solution that suits you best.

 Greetings,
 Marcus


 On 05.12.2013 17:07, Paul B. Huter wrote:
  Is there a way to make GNURadio pause before recording, and wait
  for the user to start things? It takes a few seconds for my flow to
  start up, and I would like to have control over the precise time it
  starts recording. For example, I would run the flow, but the record
  would wait until I clicked or pressed a key.
 
  Paul B. Huter
 
 
 
  ___ Discuss-gnuradio
  mailing list Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJSoLONAAoJEAFxB7BbsDrLCs0H/3qETPYomrCFTrbLi8IykbhQ
 rQNKa+IAnfnE2TtjBcFX/hkAKKZGJbPKai0kM4S523+qjQnfdk4AJwc+3LAKWWoA
 ATeSdBSZLUhh724MmGXd7Dg4acatbYfwvWxEA3TUQqesrpY2EX5bp5PuaoVDSMpr
 SrNwzOn9DaCFj9cuJBkOFcHIJ4uzI5omzW5Kqjr2uMLdzlZiHvb5LGIsg0TsC/lK
 XVWT4IY9KSO7dNKOyLm0hKQvVaavApmF337GfjxQPatN93Wx7bcktRHYlp74oRg5
 hHZ2vtd+tlknFUlv58jraFsUNqhtxMFbrTomZhVzCL+odFkyzY0E+rINvVl9FgQ=
 =rCw/
 -END PGP SIGNATURE-

 ___
 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] GNURadio Companion PAUSE

[Nick Foster]

Again, Volk has nothing to do with it. All that printout means is that your
flowgraph is now using a block which uses a Volk function for acceleration.
It has nothing to do with the problem you're seeing.

--n


On Thu, Dec 5, 2013 at 1:11 PM, Paul B. Huter paul.b.hu...@gmail.comwrote:

 Thanks! Got that working with a valve and a button. However, my flow now
 uses Volk machine, again, which doesn't record my data as well as it was
 recording before the valve (and without Volk machine). Any way to keep it
 from doing this?

 Paul B. Huter
 On Dec 5, 2013 11:11 AM, Marcus Müller mar...@hostalia.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Paul,
 use a valve together with some input widget.

 There has been great discussion over how to build a valve system the
 last month, you might need to read multiple threads to find the
 solution that suits you best.

 Greetings,
 Marcus


 On 05.12.2013 17:07, Paul B. Huter wrote:
  Is there a way to make GNURadio pause before recording, and wait
  for the user to start things? It takes a few seconds for my flow to
  start up, and I would like to have control over the precise time it
  starts recording. For example, I would run the flow, but the record
  would wait until I clicked or pressed a key.
 
  Paul B. Huter
 
 
 
  ___ Discuss-gnuradio
  mailing list Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJSoLONAAoJEAFxB7BbsDrLCs0H/3qETPYomrCFTrbLi8IykbhQ
 rQNKa+IAnfnE2TtjBcFX/hkAKKZGJbPKai0kM4S523+qjQnfdk4AJwc+3LAKWWoA
 ATeSdBSZLUhh724MmGXd7Dg4acatbYfwvWxEA3TUQqesrpY2EX5bp5PuaoVDSMpr
 SrNwzOn9DaCFj9cuJBkOFcHIJ4uzI5omzW5Kqjr2uMLdzlZiHvb5LGIsg0TsC/lK
 XVWT4IY9KSO7dNKOyLm0hKQvVaavApmF337GfjxQPatN93Wx7bcktRHYlp74oRg5
 hHZ2vtd+tlknFUlv58jraFsUNqhtxMFbrTomZhVzCL+odFkyzY0E+rINvVl9FgQ=
 =rCw/
 -END PGP SIGNATURE-

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


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


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

Re: [Discuss-gnuradio] GNURadio Companion PAUSE

[Paul B. Huter]

How do I resolve this problem, then? Is it an issue with my computing
capability?


On Thu, Dec 5, 2013 at 3:13 PM, Nick Foster bistrom...@gmail.com wrote:

 Again, Volk has nothing to do with it. All that printout means is that
 your flowgraph is now using a block which uses a Volk function for
 acceleration. It has nothing to do with the problem you're seeing.

 --n


 On Thu, Dec 5, 2013 at 1:11 PM, Paul B. Huter paul.b.hu...@gmail.comwrote:

 Thanks! Got that working with a valve and a button. However, my flow now
 uses Volk machine, again, which doesn't record my data as well as it was
 recording before the valve (and without Volk machine). Any way to keep it
 from doing this?

 Paul B. Huter
 On Dec 5, 2013 11:11 AM, Marcus Müller mar...@hostalia.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Paul,
 use a valve together with some input widget.

 There has been great discussion over how to build a valve system the
 last month, you might need to read multiple threads to find the
 solution that suits you best.

 Greetings,
 Marcus


 On 05.12.2013 17:07, Paul B. Huter wrote:
  Is there a way to make GNURadio pause before recording, and wait
  for the user to start things? It takes a few seconds for my flow to
  start up, and I would like to have control over the precise time it
  starts recording. For example, I would run the flow, but the record
  would wait until I clicked or pressed a key.
 
  Paul B. Huter
 
 
 
  ___ Discuss-gnuradio
  mailing list Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJSoLONAAoJEAFxB7BbsDrLCs0H/3qETPYomrCFTrbLi8IykbhQ
 rQNKa+IAnfnE2TtjBcFX/hkAKKZGJbPKai0kM4S523+qjQnfdk4AJwc+3LAKWWoA
 ATeSdBSZLUhh724MmGXd7Dg4acatbYfwvWxEA3TUQqesrpY2EX5bp5PuaoVDSMpr
 SrNwzOn9DaCFj9cuJBkOFcHIJ4uzI5omzW5Kqjr2uMLdzlZiHvb5LGIsg0TsC/lK
 XVWT4IY9KSO7dNKOyLm0hKQvVaavApmF337GfjxQPatN93Wx7bcktRHYlp74oRg5
 hHZ2vtd+tlknFUlv58jraFsUNqhtxMFbrTomZhVzCL+odFkyzY0E+rINvVl9FgQ=
 =rCw/
 -END PGP SIGNATURE-

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


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



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

Re: [Discuss-gnuradio] GNURadio Companion PAUSE

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Well, this is just guessing in the blue, but:
It might be the computing capability of your computer.
Not necessarily of yourself.
:D
SCNR,
Greetings,
Marcus

On 05.12.2013 22:22, Paul B. Huter wrote:
 How do I resolve this problem, then? Is it an issue with my
 computing capability?
 
 
 On Thu, Dec 5, 2013 at 3:13 PM, Nick Foster bistrom...@gmail.com
 wrote:
 
 Again, Volk has nothing to do with it. All that printout means is
 that your flowgraph is now using a block which uses a Volk
 function for acceleration. It has nothing to do with the problem
 you're seeing.
 
 --n
 
 
 On Thu, Dec 5, 2013 at 1:11 PM, Paul B. Huter
 paul.b.hu...@gmail.comwrote:
 
 Thanks! Got that working with a valve and a button. However, my
 flow now uses Volk machine, again, which doesn't record my data
 as well as it was recording before the valve (and without Volk
 machine). Any way to keep it from doing this?
 
 Paul B. Huter On Dec 5, 2013 11:11 AM, Marcus Müller
 mar...@hostalia.de wrote:
 
 Hi Paul, use a valve together with some input widget.
 
 There has been great discussion over how to build a valve system
 the last month, you might need to read multiple threads to find
 the solution that suits you best.
 
 Greetings, Marcus
 
 
 On 05.12.2013 17:07, Paul B. Huter wrote:
 Is there a way to make GNURadio pause before recording,
 and wait for the user to start things? It takes a few
 seconds for my flow to start up, and I would like to have
 control over the precise time it starts recording. For
 example, I would run the flow, but the record would wait
 until I clicked or pressed a key.
 
 Paul B. Huter
 
 
 
 ___
 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
 
 
 
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSoW41AAoJEAFxB7BbsDrLh2AH/jFcWNJvgwmbofQGEKo73Po6
kxnY97e03GwDgunnwr7FiK3HMKKZ6HpG/w7pvCcm9babgmMDsIIrFHxHOaR1F7C7
EKA4L8WQrJEmCsTNc8UqLbPVULBMTKM22b0JQiCryAgPYJ4+zMDkJdcmJgyTbONW
CtS+XpnDMYxJNlKetSXpJhk6Nm0DUt9Jt8ae4oFs4DJm6WMBpJYodLQtr/cy65wr
PCJL/X0bsw1sTex9mSKKTVaubCh1u27nwxEb5g0i0cQjxH7iFc7ssElxsgEZgRad
K0hdnU0EeENq2aYWx7D4TPdmfUxD8IMblBgkIvW4/G3vUJwi7X73dmcL7xeq2AY=
=72MV
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Gnuradio-Companion Documentation.

[Tom Rondeau]

On Thu, Sep 19, 2013 at 10:45 AM, Tim tim.oshea...@gmail.com wrote:

 Docs can take a long time to build, so when doing multiple builds a day
 during testing you really don't want to have this turned on.   Likewise if
 you are building on slow machine or an older machine without sufficient
 doxygen.   But obviously they are valuable for users doing their primary
 build who want to use the docs.

 I'm thinking it might make sense to just prompt the user when pybombs sets
 up its environment and asks for things like the prefix directory - for it to
 also ask the user whether they want to build documentation in general for
 all the recipes they will be building.

 The main issues with this are,
 1. there are not currently recipes for doxygen and it's dependencies - those
 would need to be written and would pull in a bunch of latex, perl,
 ghostscript, etc --
 2. the dependencies for gnuradio need to change based on enabling/disabling
 this feature - we don't have a good mechanism yet in pybombs for turning
 deps on or off based on recipe options, but we could add something like
 this fairly easily

 At the end of the day we do have a choice now between trying to keep build
 configurations fairly static and simple (defined only by their recipe set
 and guaranteed for repeatability - which is great for performing repeatable
 testing, versioning, and packaging) or allowing it to become a monolithic
 thing that has lots of different user prompted states and options.   It's
 not clear that we can't achieve both - but we would sacrifice a bit of
 conciseness and recipe simplicity to get there

 -Tim

At the least, we'll want to get a recipe for Doxygen, which is going
to entail a large number of dependencies, too, so it might take some
time to get all of those recipes right. At that point, it should be
easy enough to just edit gnuradio.lwr to turn on Doxygen for those who
really want it.

Also, remember that we host the documentation online, including many
of the past versions, the most recent released version, and the
current master updated weekly:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Old-docs

And one of the GSoC projects going on this year was to make some
improvements to GRC, including access to the online manual
documentation for given blocks, so requiring them to be built locally
might not be as important once we get this work rolled in.

Tom



 On 09/19/2013 09:59 AM, Tom Rondeau wrote:

 On Wed, Sep 18, 2013 at 3:48 PM, M Dammer i...@mdammer.net wrote:

 May I then suggest to enable the docs in the pybombs recipe by default
 as well ?

 You may suggest.

 Sorry for being glib. I also think it's a good idea to enable the
 documentation by default. If Tim agrees and there wasn't a technical
 reason why it was turned off in the first place, I think we can change
 it.

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

Re: [Discuss-gnuradio] Gnuradio-Companion Documentation.

[Tom Rondeau]

On Wed, Sep 18, 2013 at 3:48 PM, M Dammer i...@mdammer.net wrote:
 May I then suggest to enable the docs in the pybombs recipe by default
 as well ?

You may suggest.

Sorry for being glib. I also think it's a good idea to enable the
documentation by default. If Tim agrees and there wasn't a technical
reason why it was turned off in the first place, I think we can change
it.

-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13


 On 18/09/13 20:22, Tom Rondeau wrote:
 On Wed, Sep 18, 2013 at 3:13 PM, Kevin jplscan...@gmail.com wrote:
 Hello,

 I built Gnuradio using

 $ wget http://www.sbrac.org/files/build-gnuradio  chmod a+x
 ./build-gnuradio  ./build-gnuradio

 Which means I don't need to worry about this?

 ./configure --enable-doxygen
 make
 sudo make install
 Yeah, Kevin, that information is old (pre cmake). You probably already
 have the documentation installed (look for
 /usr/local/share/doc/gnuradio-3.X/, which could also just be under
 /usr, wherever build-gnuradio sets the prefix to).

 Building the Doxygen manual is enabled by default as long as you have
 doxygen installed on your system. You can also get access to the
 documentation for any version (and the weekly builds) here:

 http://gnuradio.org/redmine/projects/gnuradio/wiki/Old-docs

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

Re: [Discuss-gnuradio] Gnuradio-Companion Documentation.

[Tim]

Docs can take a long time to build, so when doing multiple builds a day
during testing you really don't want to have this turned on.   Likewise
if you are building on slow machine or an older machine without
sufficient doxygen.   But obviously they are valuable for users doing
their primary build who want to use the docs.

I'm thinking it might make sense to just prompt the user when pybombs
sets up its environment and asks for things like the prefix directory -
for it to also ask the user whether they want to build documentation in
general for all the recipes they will be building.   

The main issues with this are,
1. there are not currently recipes for doxygen and it's dependencies -
those would need to be written and would pull in a bunch of latex, perl,
ghostscript, etc --
2. the dependencies for gnuradio need to change based on
enabling/disabling this feature - we don't have a good mechanism yet in
pybombs for turning deps on or off based on recipe options, but we
could add something like this fairly easily

At the end of the day we do have a choice now between trying to keep
build configurations fairly static and simple (defined only by their
recipe set and guaranteed for repeatability - which is great for
performing repeatable testing, versioning, and packaging) or allowing it
to become a monolithic thing that has lots of different user prompted
states and options.   It's not clear that we can't achieve both - but we
would sacrifice a bit of conciseness and recipe simplicity to get there

-Tim


On 09/19/2013 09:59 AM, Tom Rondeau wrote:
 On Wed, Sep 18, 2013 at 3:48 PM, M Dammer i...@mdammer.net wrote:
 May I then suggest to enable the docs in the pybombs recipe by default
 as well ?
 You may suggest.

 Sorry for being glib. I also think it's a good idea to enable the
 documentation by default. If Tim agrees and there wasn't a technical
 reason why it was turned off in the first place, I think we can change
 it.


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

Re: [Discuss-gnuradio] Gnuradio-Companion Documentation.

[M Dammer]

I just had the experience of how much the documentation build process
can slow down the build in general. So I think a flag that can be
set/unset during the pybombs configuration / reconfiguration process is
a good idea. And it would make it easier for new users who a: most
likely want documentation and b: do not want to edit recipes etc.

Mark

On 19/09/13 15:45, Tim wrote:

 I'm thinking it might make sense to just prompt the user when pybombs
 sets up its environment and asks for things like the prefix directory
 - for it to also ask the user whether they want to build documentation
 in general for all the recipes they will be building.   



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

Re: [Discuss-gnuradio] Gnuradio-Companion Documentation.

[M Dammer]

Kevin, are you building gnuradio via PyBombs ? In this case you must
have doxygen installed on your system. Then you have to edit the build
recipe for gnuradio to enable doxygen:
open the file gnuradio.lwr in your pybombs/recipes folder.
in the line starting with var config_opt change -DENABLE_DOXYGEN=OFF to
-DENABLE_DOXYGEN=ON
then do start the gnuradio build:
./pybombs install gnuradio-this will do a complete rebuild
including fetching from git
./pybombs rb gnuradio  -this command just rebuilds gnuradio
(with docs) without refetching (much faster)


On 18/09/13 18:06, Kevin wrote:
 Morning,

 from the
 site, http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion
 There is the section,
 Can anybody tell me how to install it and which folder I should be at?

 Thanks


   Installing Documentation

 To view the blocks' documentation from inside GRC, install doxygen and
 configure gnuradio with doxygen support:

 ./configure --enable-doxygen
 make
 sudo make install


 ___
 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] Gnuradio-Companion Documentation.

[Tom Rondeau]

On Wed, Sep 18, 2013 at 3:13 PM, Kevin jplscan...@gmail.com wrote:
 Hello,

 I built Gnuradio using

 $ wget http://www.sbrac.org/files/build-gnuradio  chmod a+x
 ./build-gnuradio  ./build-gnuradio

 Which means I don't need to worry about this?

 ./configure --enable-doxygen
 make
 sudo make install

Yeah, Kevin, that information is old (pre cmake). You probably already
have the documentation installed (look for
/usr/local/share/doc/gnuradio-3.X/, which could also just be under
/usr, wherever build-gnuradio sets the prefix to).

Building the Doxygen manual is enabled by default as long as you have
doxygen installed on your system. You can also get access to the
documentation for any version (and the weekly builds) here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Old-docs

-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13



 On Wed, Sep 18, 2013 at 1:49 PM, M Dammer i...@mdammer.net wrote:

 Kevin, are you building gnuradio via PyBombs ? In this case you must have
 doxygen installed on your system. Then you have to edit the build recipe for
 gnuradio to enable doxygen:
 open the file gnuradio.lwr in your pybombs/recipes folder.
 in the line starting with var config_opt change -DENABLE_DOXYGEN=OFF to
 -DENABLE_DOXYGEN=ON
 then do start the gnuradio build:
 ./pybombs install gnuradio-this will do a complete rebuild
 including fetching from git
 ./pybombs rb gnuradio  -this command just rebuilds gnuradio
 (with docs) without refetching (much faster)



 On 18/09/13 18:06, Kevin wrote:

 Morning,

 from the site,
 http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion
 There is the section,
 Can anybody tell me how to install it and which folder I should be at?

 Thanks

 Installing Documentation

 To view the blocks' documentation from inside GRC, install doxygen and
 configure gnuradio with doxygen support:

 ./configure --enable-doxygen
 make
 sudo make install



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

Re: [Discuss-gnuradio] Gnuradio-Companion Documentation.

[Kevin]

Hello,

I built Gnuradio using

$ wget http://www.sbrac.org/files/build-gnuradio  chmod a+x
./build-gnuradio  ./build-gnuradio

Which means I don't need to worry about this?

./configure --enable-doxygen
make
sudo make install



On Wed, Sep 18, 2013 at 1:49 PM, M Dammer i...@mdammer.net wrote:

  Kevin, are you building gnuradio via PyBombs ? In this case you must
 have doxygen installed on your system. Then you have to edit the build
 recipe for gnuradio to enable doxygen:
 open the file gnuradio.lwr in your pybombs/recipes folder.
 in the line starting with var config_opt change -DENABLE_DOXYGEN=OFF to
 -DENABLE_DOXYGEN=ON
 then do start the gnuradio build:
 ./pybombs install gnuradio-this will do a complete rebuild
 including fetching from git
 ./pybombs rb gnuradio  -this command just rebuilds gnuradio
 (with docs) without refetching (much faster)



 On 18/09/13 18:06, Kevin wrote:

 Morning,

  from the site,
 http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion
 There is the section,
 Can anybody tell me how to install it and which folder I should be at?

  Thanks

   Installing Documentation

 To view the blocks' documentation from inside GRC, install doxygen and
 configure gnuradio with doxygen support:

 ./configure --enable-doxygen
 make
 sudo make install



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



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


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

Re: [Discuss-gnuradio] Gnuradio-Companion Documentation.

[M Dammer]

May I then suggest to enable the docs in the pybombs recipe by default
as well ?

On 18/09/13 20:22, Tom Rondeau wrote:
 On Wed, Sep 18, 2013 at 3:13 PM, Kevin jplscan...@gmail.com wrote:
 Hello,

 I built Gnuradio using

 $ wget http://www.sbrac.org/files/build-gnuradio  chmod a+x
 ./build-gnuradio  ./build-gnuradio

 Which means I don't need to worry about this?

 ./configure --enable-doxygen
 make
 sudo make install
 Yeah, Kevin, that information is old (pre cmake). You probably already
 have the documentation installed (look for
 /usr/local/share/doc/gnuradio-3.X/, which could also just be under
 /usr, wherever build-gnuradio sets the prefix to).

 Building the Doxygen manual is enabled by default as long as you have
 doxygen installed on your system. You can also get access to the
 documentation for any version (and the weekly builds) here:

 http://gnuradio.org/redmine/projects/gnuradio/wiki/Old-docs





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

Re: [Discuss-gnuradio] Gnuradio-Companion Documentation.

[Kevin]

Thank you,

So those documentation will be shown when I click block  Properties ?
That's the description below Documentation section?

Sincerely,


On Wed, Sep 18, 2013 at 2:22 PM, Tom Rondeau t...@trondeau.com wrote:

 On Wed, Sep 18, 2013 at 3:13 PM, Kevin jplscan...@gmail.com wrote:
  Hello,
 
  I built Gnuradio using
 
  $ wget http://www.sbrac.org/files/build-gnuradio  chmod a+x
  ./build-gnuradio  ./build-gnuradio
 
  Which means I don't need to worry about this?
 
  ./configure --enable-doxygen
  make
  sudo make install

 Yeah, Kevin, that information is old (pre cmake). You probably already
 have the documentation installed (look for
 /usr/local/share/doc/gnuradio-3.X/, which could also just be under
 /usr, wherever build-gnuradio sets the prefix to).

 Building the Doxygen manual is enabled by default as long as you have
 doxygen installed on your system. You can also get access to the
 documentation for any version (and the weekly builds) here:

 http://gnuradio.org/redmine/projects/gnuradio/wiki/Old-docs

 --
 Tom
 Visit us at GRCon13 Oct. 1 - 4
 http://www.trondeau.com/grcon13



  On Wed, Sep 18, 2013 at 1:49 PM, M Dammer i...@mdammer.net wrote:
 
  Kevin, are you building gnuradio via PyBombs ? In this case you must
 have
  doxygen installed on your system. Then you have to edit the build
 recipe for
  gnuradio to enable doxygen:
  open the file gnuradio.lwr in your pybombs/recipes folder.
  in the line starting with var config_opt change -DENABLE_DOXYGEN=OFF to
  -DENABLE_DOXYGEN=ON
  then do start the gnuradio build:
  ./pybombs install gnuradio-this will do a complete rebuild
  including fetching from git
  ./pybombs rb gnuradio  -this command just rebuilds gnuradio
  (with docs) without refetching (much faster)
 
 
 
  On 18/09/13 18:06, Kevin wrote:
 
  Morning,
 
  from the site,
  http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion
  There is the section,
  Can anybody tell me how to install it and which folder I should be at?
 
  Thanks
 
  Installing Documentation
 
  To view the blocks' documentation from inside GRC, install doxygen and
  configure gnuradio with doxygen support:
 
  ./configure --enable-doxygen
  make
  sudo make install
 
 

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

Re: [Discuss-gnuradio] gnuradio-companion

[Tom Rondeau]

On Mon, Jun 10, 2013 at 11:50 AM, Pratik Kumar
pratikkumar2...@gmail.com wrote:
 I am new to gnuradio.
 Can i get this channel as a block in gnuradio-companion.

Depends on what version you are using, but most likely, yes.

In the Blocks list on the right hand side of gnuradio-companion you
can find this under Channel Models (or just search for channel model
by typing in your search query after clicking into the box of blocks).

We have moved that block out of Python and reimplemented it in C++, so
you can't get exactly the block you linked to, but the C++ block
functions the same.

Tom

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

Re: [Discuss-gnuradio] gnuradio-companion

[Marcus Leech]

Assuming you're using a recent version of GRC, just start typing in the blocks window which enables a search. So typing "channel model" here will take you to the channel model.

on Jun 10, 2013, Pratik Kumar pratikkumar2...@gmail.com wrote:

I am new to gnuradio.
Can i get this channel as a block in gnuradio-companion.

http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/d5168150815339f0d3b117bcfb4d2c4265d15b33/diff/gnuradio-core/src/python/gnuradio/blks2impl/channel_model.py




___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

Re: [Discuss-gnuradio] gnuradio-companion problem

[Michael Dickens]

Hi Dan - Make sure you've installed both the gnuradio and gr-osmosdr ports with 
the +swig variant.  Without it, you do not get the *_swig import libraries.  If 
this is not the case, then email me off list and I'll help you debug the issue. 
- MLD

On May 21, 2013, at 11:11 AM, Dan Aldrich daldr...@earthlink.net wrote:
 Installed gnu radio using mac ports. First attempt was bumpy, so unistalled 
 and reinstalled again. 
 The companion comes up, but when I try a simple FM receiver (RTL-SDR - WBFM 
 - Audio Sink), I get the following:
 
 Generating: /Users/daldrich/top_block.py
 
 Executing: /Users/daldrich/top_block.py
 
 Traceback (most recent call last):
  File /Users/daldrich/top_block.py, line 17, in module
import osmosdr
  File 
 /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/__init__.py,
  line 45, in module
from osmosdr_swig import *
 ImportError: No module named osmosdr_swig


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

Re: [Discuss-gnuradio] gnuradio companion: wrong ELF class

[Marcus D. Leech]

Hello,

I am trying to run gnuradio-companion under Suse 12.3
I get the following error-message:

gnuradio-companion
Traceback (most recent call last):
   File /usr/bin/gnuradio-companion, line 67, inmodule
 from gnuradio.grc.python.Platform import Platform
   File /usr/lib64/python2.7/site-packages/gnuradio/grc/python/Platform.py, 
li\
ne 22, inmodule
 from .. base.Platform import Platform as _Platform
   File /usr/lib64/python2.7/site-packages/gnuradio/grc/base/Platform.py, 
line\
  22, inmodule
 from .. base import ParseXML, odict
   File /usr/lib64/python2.7/site-packages/gnuradio/grc/base/ParseXML.py, 
line\
  20, inmodule
 from lxml import etree
ImportError: /usr/lib/python2.7/site-packages/lxml/etree.so: wrong ELF class: E\
LFCLASS32

Apparently there is some mix of 32-Bit and 64-Bit libraries? My system is 
64-Bit.
I have installed python-lxml 2.3.4-6.1.1 using Yast.

Any hints on what might be wrong or how I can check which lib is 32-Bit?

Thanks

Wolfgang
This doesn't look like a Gnu Radio library.  Looks like the lxml 
library that was installed as part of your ssystem, and *NOT* as part of the

  Gnu Radio install.

My guess is that Yast installed the wrong thing, or that some type of 
mixed 32-bit/64-bit support option on your system is not installed.




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

Re: [Discuss-gnuradio] gnuradio-companion does not find block-ids

[Josh Blum]

 
 I started gnuradio-companion after doing all this and I get errors like
 this:
 
 line 198, in import_data
 raise LookupError('source block id %s not in block
 ids'%source_block_id)
 
 Is there an environment variable I am missing?
 

There is another thing to consider, which is where are the grc xml
definitions installed? For the gnuradio installer this is usually
installprefix/share/gnuradio/grc/blocks. I would check were the 802.15
xml files for grc got installed.

Theres also a few ways to tell GRC about new blocks if they are
installed in nonstandard places. There is a GRC_BLOCKS_PATH env var for
example. See more here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Installing-the-XML-Block-Definition

Hope that helps
-josh

 
 I am using gnuradio-3.6.2
 
 Thank you in advance for any help.
 
 Ranga
 
 
 
 
 
 
 
 ___
 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] gnuradio-companion

[Sid Boyce]

On 23/04/13 14:46, Sid Boyce wrote:

# gnuradio-config-info -v
v3.6.4.1-106-gf1dbf510

On bot x86_64 and ARM gnuradio used to work now I get a pop-up 
complaining about PYTHONPATH.
export PYTHONPATH=/usr/lib/python2.7 on ARM and export 
PYTHONPATH=/usr/lib64/python2.7 on openSUSE doesn't help.


I even rebuilt gnuradio on x86_64 in case something in an update 
caused a problem.

73 ... Sid.



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

I rebuilt gnuradio, still getting the same error with gnuradio-companion.
Cannot import gnuradio.
Presumably this is a python module which I don't have.

When I originally built gnuradio, gnuradio-companion worked on x86_64 
and on ARM.

The next time I launched it I got the error on both platforms.
Pointers please.
73 ... Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

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

Re: [Discuss-gnuradio] gnuradio-companion

[Marcus D. Leech]

On 23/04/13 14:46, Sid Boyce wrote:

# gnuradio-config-info -v
v3.6.4.1-106-gf1dbf510

On bot x86_64 and ARM gnuradio used to work now I get a pop-up 
complaining about PYTHONPATH.
export PYTHONPATH=/usr/lib/python2.7 on ARM and export 
PYTHONPATH=/usr/lib64/python2.7 on openSUSE doesn't help.


I even rebuilt gnuradio on x86_64 in case something in an update 
caused a problem.

73 ... Sid.

In fact, here's a fun little script I wrote a while back to find the 
appropriate pythonpath on your system.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

#!/bin/sh
#
# Setup PYTHONPATH
#
function pythonpath {
PYTHONPATH=unset
for mach in 64 
do
for lib in /usr/local/lib /opt/lib /usr/lib
do
for vers in 2.8 2.7 2.6 2.5
do
for pkg in site-packages dist-packages
do
td=${lib}${mach}/python${vers}/${pkg}
if [ -d $td/gnuradio ]
then
PYTHONPATH=$td
break
fi
done
if [ $PYTHONPATH != unset ]
then
break
fi
done
if [ $PYTHONPATH != unset ]
then
break
fi
done
if [ $PYTHONPATH != unset ]
then
break
fi
done
}
pythonpath
echo PYTHONPATH should be $PYTHONPATH

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

Re: [Discuss-gnuradio] gnuradio-companion

[Sid Boyce]

On 06/05/13 00:34, Marcus D. Leech wrote:

On 23/04/13 14:46, Sid Boyce wrote:

# gnuradio-config-info -v
v3.6.4.1-106-gf1dbf510

On bot x86_64 and ARM gnuradio used to work now I get a pop-up 
complaining about PYTHONPATH.
export PYTHONPATH=/usr/lib/python2.7 on ARM and export 
PYTHONPATH=/usr/lib64/python2.7 on openSUSE doesn't help.


I even rebuilt gnuradio on x86_64 in case something in an update 
caused a problem.

73 ... Sid.



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

I rebuilt gnuradio, still getting the same error with gnuradio-companion.
Cannot import gnuradio.
Presumably this is a python module which I don't have.

When I originally built gnuradio, gnuradio-companion worked on x86_64 
and on ARM.

The next time I launched it I got the error on both platforms.
Pointers please.
73 ... Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks


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

Sid:

If you had previously installed Gnu Radio from packaged binaries (with 
apt-get or the like), it will have installed under /usr


If you installed it from source (using build-gnuradio, or manually) 
all of its bits and pieces will be in /usr/local. Python packages will

  typically be installed under:

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

If you use build-gnuradio, one of the last things it does is try to 
figure out where things got installed, and suggest what you should set 
your

  PYTHONPATH to.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

Thanks Marcus,
I found the problem, python2.7 and python3.2 and python3.3 are installed 
and it was picking python3.
cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7 
-DPYTHON_INCLUDE_DIR=/usr/include/python2.7 
-DPYTHON_LIBRARY=/usr/lib64/libpython2.7.so -DCMAKE_INSTALL_PREFIX=/usr 
.. fixed it.

73 ... Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

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

Re: [Discuss-gnuradio] gnuradio-companion

[Sid Boyce]

On 06/05/13 00:39, Marcus D. Leech wrote:

On 23/04/13 14:46, Sid Boyce wrote:

# gnuradio-config-info -v
v3.6.4.1-106-gf1dbf510

On bot x86_64 and ARM gnuradio used to work now I get a pop-up 
complaining about PYTHONPATH.
export PYTHONPATH=/usr/lib/python2.7 on ARM and export 
PYTHONPATH=/usr/lib64/python2.7 on openSUSE doesn't help.


I even rebuilt gnuradio on x86_64 in case something in an update 
caused a problem.

73 ... Sid.

In fact, here's a fun little script I wrote a while back to find the 
appropriate pythonpath on your system.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

Thanks again Marcus,
The problem with the build-gnuradio script is that it is set up to build 
on Ubuntu and Fedora but no good for openSUSE.

73 ... Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

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

Re: [Discuss-gnuradio] gnuradio-companion

[Marcus D. Leech]

Thanks again Marcus,
The problem with the build-gnuradio script is that it is set up to 
build on Ubuntu and Fedora but no good for openSUSE.

73 ... Sid.

When somebody sends me a reliable recipe for building on OpenSuse (and 
detecting that it's an OpenSuse system), I'll be happy to update

  build-gnuradio to support it.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] gnuradio-companion

[Sid Boyce]

On 06/05/13 02:09, Marcus D. Leech wrote:

Thanks again Marcus,
The problem with the build-gnuradio script is that it is set up to 
build on Ubuntu and Fedora but no good for openSUSE.

73 ... Sid.

When somebody sends me a reliable recipe for building on OpenSuse (and 
detecting that it's an OpenSuse system), I'll be happy to update

  build-gnuradio to support it.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

I have the script so I'll have a look.
73 ... Sid.


--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

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

Re: [Discuss-gnuradio] gnuradio-companion

[Ralph A. Schmid, dk5ras]

Try a sudo ldconfig.

Ralph.

 -Original Message-
 From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
 [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
 Sid Boyce
 Sent: Tuesday, 23 April, 2013 15:47
 To: discuss-gnuradio@gnu.org
 Subject: [Discuss-gnuradio] gnuradio-companion
 
 # gnuradio-config-info -v
 v3.6.4.1-106-gf1dbf510
 
 On bot x86_64 and ARM gnuradio used to work now I get a pop-up
 complaining about PYTHONPATH.
 export PYTHONPATH=/usr/lib/python2.7 on ARM and export
 PYTHONPATH=/usr/lib64/python2.7 on openSUSE doesn't help.
 
 I even rebuilt gnuradio on x86_64 in case something in an update caused a
 problem.
 73 ... Sid.
 
 --
 Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus
 IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff
 Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all
 Computing Tasks



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

Re: [Discuss-gnuradio] gnuradio-companion

[Sid Boyce]

On 23/04/13 14:51, Bastian Bloessl wrote:

Hello Sid,

On 04/23/2013 03:46 PM, Sid Boyce wrote:

# gnuradio-config-info -v
v3.6.4.1-106-gf1dbf510

On bot x86_64 and ARM gnuradio used to work now I get a pop-up
complaining about PYTHONPATH.
export PYTHONPATH=/usr/lib/python2.7 on ARM and export
PYTHONPATH=/usr/lib64/python2.7 on openSUSE doesn't help.



for me that usually means I forgot
sudo ldconfig

Best,
Bastian



That's not it.
When I initially installed it, gnuradio-companion worked on openSUSE 
x86_64 and Ubuntu ARM for some days, so my guess was that something in 
subsequent updates caused the problem.


That's why I rebuilt the ARM version but got exactly the same problem.
73 ... Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks


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

Re: [Discuss-gnuradio] gnuradio-companion

[mleech]

 

On 23 Apr 2013 10:51, Sid Boyce wrote: 

 On 23/04/13 14:51,
Bastian Bloessl wrote:
 
 Hello Sid, On 04/23/2013 03:46 PM, Sid
Boyce wrote: 
 
 # gnuradio-config-info -v v3.6.4.1-106-gf1dbf510
On bot x86_64 and ARM gnuradio used to work now I get a pop-up
complaining about PYTHONPATH. export PYTHONPATH=/usr/lib/python2.7 on
ARM and export PYTHONPATH=/usr/lib64/python2.7 on openSUSE doesn't
help.
 for me that usually means I forgot sudo ldconfig Best,
Bastian
 
 That's not it.
 When I initially installed it,
gnuradio-companion worked on openSUSE 
 x86_64 and Ubuntu ARM for some
days, so my guess was that something in 
 subsequent updates caused the
problem.
 
 That's why I rebuilt the ARM version but got exactly the
same problem.
 73 ... Sid.

If you initially installed from binary, and
then installed from source, the PYTHONPATH locations are different. 

A
typical source install installs to /usr/local whereas a packaged install
installs to /usr 

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

Re: [Discuss-gnuradio] gnuradio-companion

[Sid Boyce]

I always build from source as there are some additions  from dl2stg 
needed for HiQSDR support.

I think I'll ask him to submit them upstream.

# cat /usr/src/gnuradio_audio.diff
diff --git a/gr-audio/lib/alsa/audio_alsa_source.cc 
b/gr-audio/lib/alsa/audio_alsa_source.cc

index 4f0042b..fe41e43 100644
--- a/gr-audio/lib/alsa/audio_alsa_source.cc
+++ b/gr-audio/lib/alsa/audio_alsa_source.cc
@@ -95,6 +95,7 @@ audio_alsa_source::audio_alsa_source (int sampling_rate,
   int  error;
   int  dir;

+  hwParamsSet = false;
   // open the device for capture
   error = snd_pcm_open(d_pcm_handle, d_device_name.c_str (),
   SND_PCM_STREAM_CAPTURE, 0);
@@ -231,11 +232,15 @@ audio_alsa_source::check_topology (int ninputs, 
int noutputs)

 return false;
   }

-  // set the parameters into the driver...
-  err = snd_pcm_hw_params(d_pcm_handle, d_hw_params);
-  if (err  0){
-output_error_msg (snd_pcm_hw_params failed, err);
-return false;
+  // SG
+  if (!hwParamsSet) {
+  // set the parameters into the driver...
+  err = snd_pcm_hw_params(d_pcm_handle, d_hw_params);
+  if (err  0){
+ output_error_msg (snd_pcm_hw_params failed, err);
+ return false;
+  }
+  hwParamsSet = true;
   }

   d_buffer_size_bytes =
diff --git a/gr-audio/lib/alsa/audio_alsa_source.h 
b/gr-audio/lib/alsa/audio_alsa_source.h

index e38af38..7fdcdb5 100644
--- a/gr-audio/lib/alsa/audio_alsa_source.h
+++ b/gr-audio/lib/alsa/audio_alsa_source.h
@@ -101,6 +101,9 @@ protected:
   int work_s32_2x1 (int noutput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items);
+
+private:
+  bool hwParamsSet;
 };

 #endif /* INCLUDED_AUDIO_ALSA_SOURCE_H */
73 ... Sid.


On 23/04/13 15:55, mle...@ripnet.com wrote:


On 23 Apr 2013 10:51, Sid Boyce wrote:


On 23/04/13 14:51, Bastian Bloessl wrote:

Hello Sid, On 04/23/2013 03:46 PM, Sid Boyce wrote:
# gnuradio-config-info -v v3.6.4.1-106-gf1dbf510 On bot x86_64 and 
ARM gnuradio used to work now I get a pop-up complaining about 
PYTHONPATH. export PYTHONPATH=/usr/lib/python2.7 on ARM and 
export PYTHONPATH=/usr/lib64/python2.7 on openSUSE doesn't help.

for me that usually means I forgot sudo ldconfig Best, Bastian

That's not it.
When I initially installed it, gnuradio-companion worked on openSUSE
x86_64 and Ubuntu ARM for some days, so my guess was that something in
subsequent updates caused the problem.

That's why I rebuilt the ARM version but got exactly the same problem.
73 ... Sid.


If you initially installed from binary, and then installed from 
source, the PYTHONPATH locations are different.


A typical source install installs to /usr/local  whereas a packaged 
install installs to /usr




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



--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

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

Re: [Discuss-gnuradio] gnuradio-companion hamlib bodging

[Tom Rondeau]

On Sun, Oct 28, 2012 at 5:36 PM, Darren Long darren.l...@mac.com wrote:
 Hi again,

 I've got my gnuradio 'pan-adapter' for my KX3 transceiver pretty much
 working now: http://www.g0hww.net/2012/10/gnuradio-hamlib-and-kx3.html

  but there seems to be a memory leak occurring when I call

 self.wxgui_waterfallsink2_0.set_baseband_freq(self.rig_freq)

 to update the waterfall's baseband centre frequency with the result of
 polling the transceiver (using pexpect with hamlib's rigctl).

 To be clear, the leak only occurs when set_baseband_freq() is called. if
 that line is commented out, there is no leak.

 Is this a known issue?

 Cheers,

 Darren

Hi Darren,

Great you got things working for you!

The wx stuff is all done in Python, so I'm surprised to hear of a
memory leak there. Can you confirm how big a leak it is?

Tom

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

Re: [Discuss-gnuradio] gnuradio-companion hamlib bodging

[Darren Long]

Never mind.  I've bodged it directly in the generated python.

Darren

On 28/10/12 14:35, Darren Long wrote:
 Hi,

 In gnuradio-companion,  I'm tring to control my KX3 transceiver using
 hamlib's rigctl utility.

 I've bodged a call to:
 float(pexpect.run(rigctl -m 229 -r /dev/ttyUSB0 -s 38400 f))
 in a variable block's value, and then used that to set the wxgui
 waterfall sink's baseband frequency, which works but i'm trying to
 figure out 2 more things.

 1) Can i do something similar to set the KX3's vfo frequency? a similar
 command to rigctl can be used if i can bodge the call  into Freq Set
 Varname somehow.

 2) Somehow i need to accommodate physical knobulation of the VFO on the
 radio, and keep the waterfall scale in sinc with the radio, i.e. by
 polling the same command i've used above.  Is there any chance i can do
 that via similar bodging in gnuradio-companion, or, am I actually going
 to have to write actually write some code?

 Cheers,

 Darren, G0HWW

 ___
 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] gnuradio-companion hamlib bodging

[Darren Long]

Hi again,

I've got my gnuradio 'pan-adapter' for my KX3 transceiver pretty much
working now: http://www.g0hww.net/2012/10/gnuradio-hamlib-and-kx3.html

 but there seems to be a memory leak occurring when I call

self.wxgui_waterfallsink2_0.set_baseband_freq(self.rig_freq)

to update the waterfall's baseband centre frequency with the result of
polling the transceiver (using pexpect with hamlib's rigctl).

To be clear, the leak only occurs when set_baseband_freq() is called. if
that line is commented out, there is no leak.

Is this a known issue?

Cheers,

Darren

On 28/10/12 17:55, Darren Long wrote:
 Never mind.  I've bodged it directly in the generated python.

 Darren

 On 28/10/12 14:35, Darren Long wrote:
 Hi,

 In gnuradio-companion,  I'm tring to control my KX3 transceiver using
 hamlib's rigctl utility.

 I've bodged a call to:
 float(pexpect.run(rigctl -m 229 -r /dev/ttyUSB0 -s 38400 f))
 in a variable block's value, and then used that to set the wxgui
 waterfall sink's baseband frequency, which works but i'm trying to
 figure out 2 more things.

 1) Can i do something similar to set the KX3's vfo frequency? a similar
 command to rigctl can be used if i can bodge the call  into Freq Set
 Varname somehow.

 2) Somehow i need to accommodate physical knobulation of the VFO on the
 radio, and keep the waterfall scale in sinc with the radio, i.e. by
 polling the same command i've used above.  Is there any chance i can do
 that via similar bodging in gnuradio-companion, or, am I actually going
 to have to write actually write some code?

 Cheers,

 Darren, G0HWW

 ___
 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