Re: [Discuss-gnuradio] Sigh - 16.04 build failure

[camski.watersport]

I have built a new 16.04 i386 machine and found no issue, as well have 
updated existing Ubuntu machine from 15.04 to 16.04 and have everything 
working fine except gr-fosphor which needs freetype 2. I did have to 
update pybombs from git to get the updated machine working.


Cam

On 09/05/16 02:00, Marcus Müller wrote:

Mike,
!

CppUnit is a long-standing dependency of GNU Radio, and this is really
surprising.
I'm currently looking at libcppunit.a from 16.04's libcppunit-dev.deb
package; it definitely contains all the symbols.

Sooo my guess is that gcc/ld tries to use the libcppunit.so (which seems
to be stripped of all symbols under Ubuntu 16.04) instead of the
development library libcppunit.a (which would be consistent with what
the ld documentation says).

I must admit that this is something new, and I don't know how we can
deal with it, so hopefully, someone else can chime in.


Best regards,
Marcus


On 08.05.2016 10:24, Mike wrote:

For some reason - this data doesn't appear in the file!

PyBombs._process_thread() - DEBUG - Executing command `make -j4'
CMakeFiles/gr_runtime_test.dir/test_runtime.cc.o: In function `main':
/home/mike/gnuradio/src/gnuradio/gnuradio-runtime/lib/test_runtime.cc:39:
undefined reference to
`CppUnit::XmlOutputter::XmlOutputter(CppUnit::TestResultCollector*,
std::ostream&, std::__cxx11::basic_string, std::allocator >)'
/home/mike/gnuradio/src/gnuradio/gnuradio-runtime/lib/test_runtime.cc:44:
undefined reference to
`CppUnit::TextTestRunner::run(std::__cxx11::basic_string, std::allocator >, bool, bool, bool)'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::Test::findTest(std::__cxx11::basic_string, std::allocator > const&) const'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::TypeInfoHelper::getClassName[abi:cxx11](std::type_info const&)'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::SourceLine::SourceLine(std::__cxx11::basic_string, std::allocator > const&, int)'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::Test::resolveTestPath(std::__cxx11::basic_string, std::allocator > const&) const'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::Asserter::failNotEqual(std::__cxx11::basic_string, std::allocator >,
std::__cxx11::basic_string,
std::allocator >, CppUnit::SourceLine const&,
CppUnit::AdditionalMessage const&, std::__cxx11::basic_string, std::allocator >)'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::TestCase::getName[abi:cxx11]() const'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::TestCase::TestCase(std::__cxx11::basic_string, std::allocator > const&)'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::TestSuite::TestSuite(std::__cxx11::basic_string, std::allocator >)'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::TestSuiteBuilderContextBase::getTestNameFor(std::__cxx11::basic_string, std::allocator > const&) const'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::Message::Message(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&)'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::assertDoubleEquals(double, double, double,
CppUnit::SourceLine, std::__cxx11::basic_string, std::allocator > const&)'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::TestCaseDecorator::getName[abi:cxx11]() const'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::Test::findTestPath(std::__cxx11::basic_string, std::allocator > const&,
CppUnit::TestPath&) const'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::AdditionalMessage::AdditionalMessage(std::__cxx11::basic_string, std::allocator > const&)'
libtest-gnuradio-runtime.so: undefined reference to
`CppUnit::TestNamer::getFixtureName[abi:cxx11]() const'
collect2: error: ld returned 1 exit status
make[2]: *** [gnuradio-runtime/lib/gr_runtime_test] Error 1
make[1]: *** [gnuradio-runtime/lib/CMakeFiles/gr_runtime_test.dir/all]
Error 2
make[1]: *** Waiting for unfinished jobs
CMakeFiles/gr_pmt_test.dir/test_pmt.cc.o: In function `main':
/home/mike/gnuradio/src/gnuradio/gnuradio-runtime/lib/pmt/test_pmt.cc:39:
undefined reference to
`CppUnit::XmlOutputter::XmlOutputter(CppUnit::TestResultCollector*,
std::ostream&, std::__cxx11::basic_string, std::allocator >)'
/home/mike/gnuradio/src/gnuradio/gnuradio-runtime/lib/pmt/test_pmt.cc:44:
undefined reference to
`CppUnit::TextTestRunner::run(std::__cxx11::basic_string, std::allocator >, bool, bool, bool)'
libtest-gnuradio-pmt.so: undefined reference to
`CppUnit::Test::findTest(std::__cxx11::basic_string, std::allocator > const&) const'
libtest-gnuradio-pmt.so: undefined reference to
`CppUnit::TypeInfoHelper::getClassName[abi:cxx11](std::type_info const&)'
libtest-gnuradio-pmt.so: undefined reference to
`CppUnit::SourceLine::SourceLine(std::__cxx11::basic_string, std::allocator > const&, int)'
libtest-gnuradio-pmt.so: undefined reference to
`CppUnit::Test::

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Marcus Müller]

Hi Tony,

> The lack of path separators is troubling.

I couldn't agree more. But since that just means that the separator
get's "eaten" somewhere, and we don't know whether that happens when
generating these paths or just when printing, I'm still full of hope…
> The fact these directories don't exist on my machine (even with
> appropriate separators) is more troubling.  
… my hopes being crushed.

> Is there a way to override the default values?

Yes, but not at runtime, I'm afraid: The "first" directory a program
looks into for configuration has to be hard-coded somewhere, and in the
case of GNU Radio, it's specified via the GR_PREFSDIR CMake Variable
when building GNU Radio.
That happens in the gnuradio/gnuradio/lib/constants.cc.in file, where
CMake expands the @GR_PREFSDIR@ macro.  The actual setting of that
variable happens in the main gnuradio/CMakeLists.txt, line 165

   set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH "System 
configuration directory" FORCE)

so we learn that CMAKE_INSTALL_PREFIX was set to
C:gr-buildsrc-stage3staged_install, plus a few \, probably :D

So that's essentially where I'd have to give up: That code was put there
during build, and I can't change it later.

What I'll probably do is a bug report about GNU Radio, upon finding the
prefsdir path not to be a directory (in your case: not to exist at all)
giving up and not even trying to read any other paths. I might fix that
by allowing users to specify these directories as environment variables;
that would make sense to me, but as it kind of changes "logical" API,
I'd like to discuss this with a maintainer.

I think I might come up with a workaround, however. Again, I haven't
tried this, especially not under windows, where the whole "launch an
editor and edit that file" aspect might fail, but *shrug*:

In your GRC flow graph, add a "python module".
There, without indenting, add the following code

from gnuradio import gr
p = gr.prefs()
p.set_string("audio","audio_module","portaudio")

and close the editor. Basically, you're setting the configuration option
manually for the meantime.

Best regards,
Marcus

On 09.05.2016 04:38, Tony Richardson wrote:
> The command:
> gnuradio-config-info --prefsdir --sysconfdir
> returns
>
>   C:gr-buildsrc-stage3staged_installReleaseetc
>   C:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
>
> The lack of path separators is troubling.  The fact these directories
> don't exist on my machine (even with appropriate separators) is more
> troubling.  I assume this is why config files in the installed etc
> directory are not being read.  After using the Windows installer, I
> have what appear to be corresponding directories here:
>
>   C:\Program Files\GNURadio-3.7\etc
>   C:\Program Files\GNURadio-3.7\etc\gnuradio\conf.d
>
> I have a HOME environment variable defined in Windows, so I think GRC
> is looking in $HOME/.gnuradio for a config.conf file.  Running GRC
> actually creates a $HOME/.gnuradio directory and places some
> configuration files in that directory, but doesn't appear to read from
> it.  I also tried putting a config.conf file in the APPDATA/.gnuradio
> directory but it isn't being read either.
>
> Is there a way to override the default values?
>
> Tony Richardson
>
> On Sat, May 7, 2016 at 9:05 AM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> Sooo gnuradio-runtime/lib/prefs.cc:
>
>  77 // Find if there is a ~/.gnuradio/config.conf file and add this to
>  78 // the end of the file list to override any preferences in the
>  79 // installed path config files.
>  80 fs::path homedir = fs::path(gr::appdata_path());
>  81 homedir = homedir/".gnuradio/config.conf";
>  82 if(fs::exists(homedir)) {
>  83   fnames.push_back(homedir.string());
>  84 }
>  85 
>
> This means that things in Users/youruser/Application
> Data/.gnuradio/config.conf *should* be read.
>
>> I also tried changing the canvas size in the "c:/Program
>> Files/GNURadio-3.7/etc/gnuradio/conf.d/grc.conf" file, which I
>> think is supposed to be the system-wide file, but changes there
>> have no effect either.
> Uh-oh.
>
> Can you execute a
>
> gnuradio-config-info --prefsdir --sysconfdir 
>
> please?
>
> Back to topic:
>> Is there a way for me to figure out what configuration files are
>> being read?
>
> I'm really not experienced Windows debugger; under Unixes, I'd do
> run like (to trace all "stat" calls, ie. when the code above
> checks for the existence of config.conf)
>
> strace -e stat  -o '|grep config.conf'  gnuradio-config-info -v
>
>
> but I really don't know whether that even works in theory under
> Windows.
>
> I'm a bit worried about this line:
>
>  81 homedir = homedir/".gnuradio/config.conf";
>
> Because it implicitly assumes that the OS considers "/" as path
> separator between

[Discuss-gnuradio] gr-dsd and gqrx

[Ekko]

hello all
i see this here
https://www.youtube.com/watch?v=yaio4YxwcBg
and i want to know how to add the
gr-dsd
https://github.com/argilo/gr-dsd
to the gqrx ,just like the vedio showed
are there some instructions or some ways to get this done.

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

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Tony Richardson]

There appear to be some problems with "python module"s in Windows GRC too.
I get an error that the editor can't find a particular file.  If I add the
python block in GRC, then have it generate code and add the code to the
corresponding Python file from an external editor - I can then run the top
level Python file from a command prompt and it works!  (Appears to be using
portaudio).

If I try to execute from GRC it replaces my Python source with a file
containing the line:

   # this module will be imported in the into your flowgraph

and will not run anymore.

Thanks for your help, but I agree that it is time to give up.

Tony


On Mon, May 9, 2016 at 3:45 AM, Marcus Müller 
wrote:

> Hi Tony,
>
> > The lack of path separators is troubling.
>
> I couldn't agree more. But since that just means that the separator get's
> "eaten" somewhere, and we don't know whether that happens when generating
> these paths or just when printing, I'm still full of hope…
>
> The fact these directories don't exist on my machine (even with
> appropriate separators) is more troubling.
>
> … my hopes being crushed.
>
> > Is there a way to override the default values?
>
> Yes, but not at runtime, I'm afraid: The "first" directory a program looks
> into for configuration has to be hard-coded somewhere, and in the case of
> GNU Radio, it's specified via the GR_PREFSDIR CMake Variable when building
> GNU Radio.
> That happens in the gnuradio/gnuradio/lib/constants.cc.in file, where
> CMake expands the @GR_PREFSDIR@ macro.  The actual setting of that
> variable happens in the main gnuradio/CMakeLists.txt, line 165
>
>set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH "System 
> configuration directory" FORCE)
>
> so we learn that CMAKE_INSTALL_PREFIX was set to
> C:gr-buildsrc-stage3staged_install, plus a few \, probably :D
>
> So that's essentially where I'd have to give up: That code was put there
> during build, and I can't change it later.
>
> What I'll probably do is a bug report about GNU Radio, upon finding the
> prefsdir path not to be a directory (in your case: not to exist at all)
> giving up and not even trying to read any other paths. I might fix that by
> allowing users to specify these directories as environment variables; that
> would make sense to me, but as it kind of changes "logical" API, I'd like
> to discuss this with a maintainer.
>
> I think I might come up with a workaround, however. Again, I haven't tried
> this, especially not under windows, where the whole "launch an editor and
> edit that file" aspect might fail, but *shrug*:
>
> In your GRC flow graph, add a "python module".
> There, without indenting, add the following code
>
> from gnuradio import gr
> p = gr.prefs()
> p.set_string("audio","audio_module","portaudio")
>
> and close the editor. Basically, you're setting the configuration option
> manually for the meantime.
>
> Best regards,
> Marcus
>
>
> On 09.05.2016 04:38, Tony Richardson wrote:
>
> The command:
>
> gnuradio-config-info --prefsdir --sysconfdir
>
> returns
>
>   C:gr-buildsrc-stage3staged_installReleaseetc
>   C:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
>
> The lack of path separators is troubling.  The fact these directories
> don't exist on my machine (even with appropriate separators) is more
> troubling.  I assume this is why config files in the installed etc
> directory are not being read.  After using the Windows installer, I have
> what appear to be corresponding directories here:
>
>   C:\Program Files\GNURadio-3.7\etc
>   C:\Program Files\GNURadio-3.7\etc\gnuradio\conf.d
>
> I have a HOME environment variable defined in Windows, so I think GRC is
> looking in $HOME/.gnuradio for a config.conf file.  Running GRC actually
> creates a $HOME/.gnuradio directory and places some configuration files in
> that directory, but doesn't appear to read from it.  I also tried putting a
> config.conf file in the APPDATA/.gnuradio directory but it isn't being read
> either.
>
> Is there a way to override the default values?
>
> Tony Richardson
>
> On Sat, May 7, 2016 at 9:05 AM, Marcus Müller 
> wrote:
>
>> Sooo gnuradio-runtime/lib/prefs.cc:
>>
>>  77 // Find if there is a ~/.gnuradio/config.conf file and add this to
>>  78 // the end of the file list to override any preferences in the
>>  79 // installed path config files.
>>  80 fs::path homedir = fs::path(gr::appdata_path());
>>  81 homedir = homedir/".gnuradio/config.conf";
>>  82 if(fs::exists(homedir)) {
>>  83   fnames.push_back(homedir.string());
>>  84 }
>>  85
>>
>>
>> This means that things in Users/youruser/Application
>> Data/.gnuradio/config.conf *should* be read.
>>
>> I also tried changing the canvas size in the "c:/Program
>> Files/GNURadio-3.7/etc/gnuradio/conf.d/grc.conf" file, which I think is
>> supposed to be the system-wide file, but changes there have no effect
>> either.
>>
>> Uh-oh.
>>
>> Can you execute a
>>
>> gnuradio-config-info

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Geof Nieboer]

Tony,

Getting the Windows audio source to work is on my "to do" list.  I
reworked the sink already, so I don't think it will be difficult to do the
source either.

The hard coded paths are troublesome, as using a Windows installer
that allows users to install in any path they desire after everything has
already been compiled is fundamentally incompatible with hardcoded paths at
compile time.   One potential way to implement Marcus's suggestion might be
to incorporate it into the run_gr.bat file that sets the gnu radio
environment prior to running the python script.

As you probably already surmised, the directories referenced that you
saw are exactly where the build scripts originally built gnuradio prior to
packing it into an .msi.

Geof

On Monday, May 9, 2016, Tony Richardson  wrote:

> There appear to be some problems with "python module"s in Windows GRC
> too.  I get an error that the editor can't find a particular file.  If I
> add the python block in GRC, then have it generate code and add the code to
> the corresponding Python file from an external editor - I can then run the
> top level Python file from a command prompt and it works!  (Appears to be
> using portaudio).
>
> If I try to execute from GRC it replaces my Python source with a file
> containing the line:
>
># this module will be imported in the into your flowgraph
>
> and will not run anymore.
>
> Thanks for your help, but I agree that it is time to give up.
>
> Tony
>
>
> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller  > wrote:
>
>> Hi Tony,
>>
>> > The lack of path separators is troubling.
>>
>> I couldn't agree more. But since that just means that the separator get's
>> "eaten" somewhere, and we don't know whether that happens when generating
>> these paths or just when printing, I'm still full of hope…
>>
>> The fact these directories don't exist on my machine (even with
>> appropriate separators) is more troubling.
>>
>> … my hopes being crushed.
>>
>> > Is there a way to override the default values?
>>
>> Yes, but not at runtime, I'm afraid: The "first" directory a program
>> looks into for configuration has to be hard-coded somewhere, and in the
>> case of GNU Radio, it's specified via the GR_PREFSDIR CMake Variable when
>> building GNU Radio.
>> That happens in the gnuradio/gnuradio/lib/constants.cc.in file, where
>> CMake expands the @GR_PREFSDIR@ macro.  The actual setting of that
>> variable happens in the main gnuradio/CMakeLists.txt, line 165
>>
>>set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH 
>> "System configuration directory" FORCE)
>>
>> so we learn that CMAKE_INSTALL_PREFIX was set to
>> C:gr-buildsrc-stage3staged_install, plus a few \, probably :D
>>
>> So that's essentially where I'd have to give up: That code was put there
>> during build, and I can't change it later.
>>
>> What I'll probably do is a bug report about GNU Radio, upon finding the
>> prefsdir path not to be a directory (in your case: not to exist at all)
>> giving up and not even trying to read any other paths. I might fix that by
>> allowing users to specify these directories as environment variables; that
>> would make sense to me, but as it kind of changes "logical" API, I'd like
>> to discuss this with a maintainer.
>>
>> I think I might come up with a workaround, however. Again, I haven't
>> tried this, especially not under windows, where the whole "launch an editor
>> and edit that file" aspect might fail, but *shrug*:
>>
>> In your GRC flow graph, add a "python module".
>> There, without indenting, add the following code
>>
>> from gnuradio import gr
>> p = gr.prefs()
>> p.set_string("audio","audio_module","portaudio")
>>
>> and close the editor. Basically, you're setting the configuration option
>> manually for the meantime.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 09.05.2016 04:38, Tony Richardson wrote:
>>
>> The command:
>>
>> gnuradio-config-info --prefsdir --sysconfdir
>>
>> returns
>>
>>   C:gr-buildsrc-stage3staged_installReleaseetc
>>   C:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
>>
>> The lack of path separators is troubling.  The fact these directories
>> don't exist on my machine (even with appropriate separators) is more
>> troubling.  I assume this is why config files in the installed etc
>> directory are not being read.  After using the Windows installer, I have
>> what appear to be corresponding directories here:
>>
>>   C:\Program Files\GNURadio-3.7\etc
>>   C:\Program Files\GNURadio-3.7\etc\gnuradio\conf.d
>>
>> I have a HOME environment variable defined in Windows, so I think GRC is
>> looking in $HOME/.gnuradio for a config.conf file.  Running GRC actually
>> creates a $HOME/.gnuradio directory and places some configuration files in
>> that directory, but doesn't appear to read from it.  I also tried putting a
>> config.conf file in the APPDATA/.gnuradio directory but it isn't being read
>> either.
>>
>> Is there a way to override the default values?
>>
>> Tony R

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Marcus Müller]

Hi Tony,

to be honest, I'll be rewriting GNU Radio's slightly dated and slightly
ugly preference system, as it seems, so I'm not 100% giving up on this.
So, I hope the spirit of the workaround was clear to you: you can always
manually set this particular setting via python (instead of specifying
it in a configuration file).
The python module "detour" was just an attempt to make that a permanent
feature of the flow graph. Instead, I could have just asked you to add
it pretty far up in the generated top_block.py (or whatever your
generated python file is called). There's also another way of specifying
such settings – environment variables (which under windows are
especially little fun to set...).
You can (as documented in [1]) specify a setting as an environment
variable; in your case, something like

GR_CONF_audio_audio_module = portaudio

I know you can configure environment variables /somewhere  /in windows,
but I forget where – my Windows usage is just too rare.

Best regards,
Marcus

[1] http://gnuradio.org/doc/doxygen/page_prefs.html

On 09.05.2016 14:33, Tony Richardson wrote:
> There appear to be some problems with "python module"s in Windows GRC
> too.  I get an error that the editor can't find a particular file.  If
> I add the python block in GRC, then have it generate code and add the
> code to the corresponding Python file from an external editor - I can
> then run the top level Python file from a command prompt and it works!
>  (Appears to be using portaudio).
>
> If I try to execute from GRC it replaces my Python source with a file
> containing the line:
>
># this module will be imported in the into your flowgraph
>
> and will not run anymore.
>
> Thanks for your help, but I agree that it is time to give up.
>
> Tony
>
>
> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> Hi Tony,
>
> > The lack of path separators is troubling.
>
> I couldn't agree more. But since that just means that the
> separator get's "eaten" somewhere, and we don't know whether that
> happens when generating these paths or just when printing, I'm
> still full of hope…
>> The fact these directories don't exist on my machine (even with
>> appropriate separators) is more troubling.  
> … my hopes being crushed.
>
> > Is there a way to override the default values?
>
> Yes, but not at runtime, I'm afraid: The "first" directory a
> program looks into for configuration has to be hard-coded
> somewhere, and in the case of GNU Radio, it's specified via the
> GR_PREFSDIR CMake Variable when building GNU Radio.
> That happens in the gnuradio/gnuradio/lib/constants.cc.in
>  file, where CMake expands the
> @GR_PREFSDIR@ macro.  The actual setting of that variable happens
> in the main gnuradio/CMakeLists.txt, line 165
>
>set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH 
> "System configuration directory" FORCE)
>
> so we learn that CMAKE_INSTALL_PREFIX was set to
> C:gr-buildsrc-stage3staged_install, plus a few \, probably :D
>
> So that's essentially where I'd have to give up: That code was put
> there during build, and I can't change it later.
>
> What I'll probably do is a bug report about GNU Radio, upon
> finding the prefsdir path not to be a directory (in your case: not
> to exist at all) giving up and not even trying to read any other
> paths. I might fix that by allowing users to specify these
> directories as environment variables; that would make sense to me,
> but as it kind of changes "logical" API, I'd like to discuss this
> with a maintainer.
>
> I think I might come up with a workaround, however. Again, I
> haven't tried this, especially not under windows, where the whole
> "launch an editor and edit that file" aspect might fail, but *shrug*:
>
> In your GRC flow graph, add a "python module".
> There, without indenting, add the following code
>
> from gnuradio import gr
> p = gr.prefs()
> p.set_string("audio","audio_module","portaudio")
>
> and close the editor. Basically, you're setting the configuration
> option manually for the meantime.
>
> Best regards,
> Marcus
>
>
> On 09.05.2016 04:38, Tony Richardson wrote:
>> The command:
>> gnuradio-config-info --prefsdir --sysconfdir
>> returns
>>
>>   C:gr-buildsrc-stage3staged_installReleaseetc
>>   C:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
>>
>> The lack of path separators is troubling.  The fact these
>> directories don't exist on my machine (even with appropriate
>> separators) is more troubling.  I assume this is why config files
>> in the installed etc directory are not being read.  After using
>> the Windows installer, I have what appear to be corresponding
>> directories here:
>>
>>   C:\Program Files\GNURadio-3.7\etc
>>

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Marcus Müller]

Hi Geof,

as I'm currently thinking about how we'd want GNU Radio to /actually
behave/ when looking for config files, I'd like to ask you a question
regarding generation of the installer:

How do you do it? Are you letting CMake install everything in a "clean
slate prefix", and then just package that up and ship it as an .msi, or
is there some magic CMake install() hooks that actually do "note down"
what should get installed where?

Point is that what we have as global configuration under under Unixes
usually ends up in  {prefix, if any}/etc/gnuradio/conf.d, but on
windows, there only seems to be %appdata% – which looks like it would be
different between different versions of windows. Hence my question is
how I could tell an installer (your installer?) where to put
configuration files.

Best regards, and thanks for all the work!

Marcus

On 09.05.2016 16:06, Geof Nieboer wrote:
> Tony,
>
> Getting the Windows audio source to work is on my "to do" list.  I
> reworked the sink already, so I don't think it will be difficult to do
> the source either.
>
> The hard coded paths are troublesome, as using a Windows installer
> that allows users to install in any path they desire after everything
> has already been compiled is fundamentally incompatible with hardcoded
> paths at compile time.   One potential way to implement Marcus's
> suggestion might be to incorporate it into the run_gr.bat file that
> sets the gnu radio environment prior to running the python script.
>
> As you probably already surmised, the directories referenced that you
> saw are exactly where the build scripts originally built gnuradio
> prior to packing it into an .msi.  
>
> Geof
>
> On Monday, May 9, 2016, Tony Richardson  > wrote:
>
> There appear to be some problems with "python module"s in Windows
> GRC too.  I get an error that the editor can't find a particular
> file.  If I add the python block in GRC, then have it generate
> code and add the code to the corresponding Python file from an
> external editor - I can then run the top level Python file from a
> command prompt and it works!  (Appears to be using portaudio).
>
> If I try to execute from GRC it replaces my Python source with a
> file containing the line:
>
># this module will be imported in the into your flowgraph
>
> and will not run anymore.
>
> Thanks for your help, but I agree that it is time to give up.
>
> Tony
>
>
> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller
>  > wrote:
>
> Hi Tony,
>
> > The lack of path separators is troubling.
>
> I couldn't agree more. But since that just means that the
> separator get's "eaten" somewhere, and we don't know whether
> that happens when generating these paths or just when
> printing, I'm still full of hope…
>> The fact these directories don't exist on my machine (even
>> with appropriate separators) is more troubling.  
> … my hopes being crushed.
>
> > Is there a way to override the default values?
>
> Yes, but not at runtime, I'm afraid: The "first" directory a
> program looks into for configuration has to be hard-coded
> somewhere, and in the case of GNU Radio, it's specified via
> the GR_PREFSDIR CMake Variable when building GNU Radio.
> That happens in the gnuradio/gnuradio/lib/constants.cc.in
>  file, where CMake expands the
> @GR_PREFSDIR@ macro.  The actual setting of that variable
> happens in the main gnuradio/CMakeLists.txt, line 165
>
>set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH 
> "System configuration directory" FORCE)
>
> so we learn that CMAKE_INSTALL_PREFIX was set to
> C:gr-buildsrc-stage3staged_install, plus a few \, probably :D
>
> So that's essentially where I'd have to give up: That code was
> put there during build, and I can't change it later.
>
> What I'll probably do is a bug report about GNU Radio, upon
> finding the prefsdir path not to be a directory (in your case:
> not to exist at all) giving up and not even trying to read any
> other paths. I might fix that by allowing users to specify
> these directories as environment variables; that would make
> sense to me, but as it kind of changes "logical" API, I'd like
> to discuss this with a maintainer.
>
> I think I might come up with a workaround, however. Again, I
> haven't tried this, especially not under windows, where the
> whole "launch an editor and edit that file" aspect might fail,
> but *shrug*:
>
> In your GRC flow graph, add a "python module".
> There, without indenting, add the following code
>
> from gnuradio import gr
> p = gr.prefs()
> p.set_string("audio","audio_module","portaudio")
>

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Tony Richardson]

Thanks Geof.  A Windows audio source would be great.  Just to be clear
though, because I started down this path by first trying to get GRC to
process my config.conf file.  I never succeeded.  Is this a known problem?

Tony

On Mon, May 9, 2016 at 9:06 AM, Geof Nieboer  wrote:

> Tony,
>
> Getting the Windows audio source to work is on my "to do" list.  I
> reworked the sink already, so I don't think it will be difficult to do the
> source either.
>
> The hard coded paths are troublesome, as using a Windows installer
> that allows users to install in any path they desire after everything has
> already been compiled is fundamentally incompatible with hardcoded paths at
> compile time.   One potential way to implement Marcus's suggestion might be
> to incorporate it into the run_gr.bat file that sets the gnu radio
> environment prior to running the python script.
>
> As you probably already surmised, the directories referenced that you
> saw are exactly where the build scripts originally built gnuradio prior to
> packing it into an .msi.
>
> Geof
>
>
> On Monday, May 9, 2016, Tony Richardson  wrote:
>
>> There appear to be some problems with "python module"s in Windows GRC
>> too.  I get an error that the editor can't find a particular file.  If I
>> add the python block in GRC, then have it generate code and add the code to
>> the corresponding Python file from an external editor - I can then run the
>> top level Python file from a command prompt and it works!  (Appears to be
>> using portaudio).
>>
>> If I try to execute from GRC it replaces my Python source with a file
>> containing the line:
>>
>># this module will be imported in the into your flowgraph
>>
>> and will not run anymore.
>>
>> Thanks for your help, but I agree that it is time to give up.
>>
>> Tony
>>
>>
>> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller 
>> wrote:
>>
>>> Hi Tony,
>>>
>>> > The lack of path separators is troubling.
>>>
>>> I couldn't agree more. But since that just means that the separator
>>> get's "eaten" somewhere, and we don't know whether that happens when
>>> generating these paths or just when printing, I'm still full of hope…
>>>
>>> The fact these directories don't exist on my machine (even with
>>> appropriate separators) is more troubling.
>>>
>>> … my hopes being crushed.
>>>
>>> > Is there a way to override the default values?
>>>
>>> Yes, but not at runtime, I'm afraid: The "first" directory a program
>>> looks into for configuration has to be hard-coded somewhere, and in the
>>> case of GNU Radio, it's specified via the GR_PREFSDIR CMake Variable when
>>> building GNU Radio.
>>> That happens in the gnuradio/gnuradio/lib/constants.cc.in file, where
>>> CMake expands the @GR_PREFSDIR@ macro.  The actual setting of that
>>> variable happens in the main gnuradio/CMakeLists.txt, line 165
>>>
>>>set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH 
>>> "System configuration directory" FORCE)
>>>
>>> so we learn that CMAKE_INSTALL_PREFIX was set to
>>> C:gr-buildsrc-stage3staged_install, plus a few \, probably :D
>>>
>>> So that's essentially where I'd have to give up: That code was put there
>>> during build, and I can't change it later.
>>>
>>> What I'll probably do is a bug report about GNU Radio, upon finding the
>>> prefsdir path not to be a directory (in your case: not to exist at all)
>>> giving up and not even trying to read any other paths. I might fix that by
>>> allowing users to specify these directories as environment variables; that
>>> would make sense to me, but as it kind of changes "logical" API, I'd like
>>> to discuss this with a maintainer.
>>>
>>> I think I might come up with a workaround, however. Again, I haven't
>>> tried this, especially not under windows, where the whole "launch an editor
>>> and edit that file" aspect might fail, but *shrug*:
>>>
>>> In your GRC flow graph, add a "python module".
>>> There, without indenting, add the following code
>>>
>>> from gnuradio import gr
>>> p = gr.prefs()
>>> p.set_string("audio","audio_module","portaudio")
>>>
>>> and close the editor. Basically, you're setting the configuration option
>>> manually for the meantime.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 09.05.2016 04:38, Tony Richardson wrote:
>>>
>>> The command:
>>>
>>> gnuradio-config-info --prefsdir --sysconfdir
>>>
>>> returns
>>>
>>>   C:gr-buildsrc-stage3staged_installReleaseetc
>>>   C:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
>>>
>>> The lack of path separators is troubling.  The fact these directories
>>> don't exist on my machine (even with appropriate separators) is more
>>> troubling.  I assume this is why config files in the installed etc
>>> directory are not being read.  After using the Windows installer, I have
>>> what appear to be corresponding directories here:
>>>
>>>   C:\Program Files\GNURadio-3.7\etc
>>>   C:\Program Files\GNURadio-3.7\etc\gnuradio\conf.d
>>>
>>> I have a HOME environment variable defined in

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Tony Richardson]

Thanks Marcus.

I just set the environment variable that you mentioned in the run_gr.bat
file that Geof mentioned and portaudio now works.  I realize it is not a
clean solution, but it is a working one.  I am happy.

Tony





On Mon, May 9, 2016 at 9:42 AM, Marcus Müller 
wrote:

> Hi Tony,
>
> to be honest, I'll be rewriting GNU Radio's slightly dated and slightly
> ugly preference system, as it seems, so I'm not 100% giving up on this.
> So, I hope the spirit of the workaround was clear to you: you can always
> manually set this particular setting via python (instead of specifying it
> in a configuration file).
> The python module "detour" was just an attempt to make that a permanent
> feature of the flow graph. Instead, I could have just asked you to add it
> pretty far up in the generated top_block.py (or whatever your generated
> python file is called). There's also another way of specifying such
> settings – environment variables (which under windows are especially little
> fun to set...).
> You can (as documented in [1]) specify a setting as an environment
> variable; in your case, something like
>
> GR_CONF_audio_audio_module = portaudio
>
> I know you can configure environment variables *somewhere  *in windows,
> but I forget where – my Windows usage is just too rare.
>
> Best regards,
> Marcus
>
> [1] http://gnuradio.org/doc/doxygen/page_prefs.html
>
>
> On 09.05.2016 14:33, Tony Richardson wrote:
>
> There appear to be some problems with "python module"s in Windows GRC
> too.  I get an error that the editor can't find a particular file.  If I
> add the python block in GRC, then have it generate code and add the code to
> the corresponding Python file from an external editor - I can then run the
> top level Python file from a command prompt and it works!  (Appears to be
> using portaudio).
>
> If I try to execute from GRC it replaces my Python source with a file
> containing the line:
>
># this module will be imported in the into your flowgraph
>
> and will not run anymore.
>
> Thanks for your help, but I agree that it is time to give up.
>
> Tony
>
>
> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller 
> wrote:
>
>> Hi Tony,
>>
>> > The lack of path separators is troubling.
>>
>> I couldn't agree more. But since that just means that the separator get's
>> "eaten" somewhere, and we don't know whether that happens when generating
>> these paths or just when printing, I'm still full of hope…
>>
>> The fact these directories don't exist on my machine (even with
>> appropriate separators) is more troubling.
>>
>> … my hopes being crushed.
>>
>> > Is there a way to override the default values?
>>
>> Yes, but not at runtime, I'm afraid: The "first" directory a program
>> looks into for configuration has to be hard-coded somewhere, and in the
>> case of GNU Radio, it's specified via the GR_PREFSDIR CMake Variable when
>> building GNU Radio.
>> That happens in the gnuradio/gnuradio/lib/constants.cc.in file, where
>> CMake expands the @GR_PREFSDIR@ macro.  The actual setting of that
>> variable happens in the main gnuradio/CMakeLists.txt, line 165
>>
>>set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH 
>> "System configuration directory" FORCE)
>>
>> so we learn that CMAKE_INSTALL_PREFIX was set to
>> C:gr-buildsrc-stage3staged_install, plus a few \, probably :D
>>
>> So that's essentially where I'd have to give up: That code was put there
>> during build, and I can't change it later.
>>
>> What I'll probably do is a bug report about GNU Radio, upon finding the
>> prefsdir path not to be a directory (in your case: not to exist at all)
>> giving up and not even trying to read any other paths. I might fix that by
>> allowing users to specify these directories as environment variables; that
>> would make sense to me, but as it kind of changes "logical" API, I'd like
>> to discuss this with a maintainer.
>>
>> I think I might come up with a workaround, however. Again, I haven't
>> tried this, especially not under windows, where the whole "launch an editor
>> and edit that file" aspect might fail, but *shrug*:
>>
>> In your GRC flow graph, add a "python module".
>> There, without indenting, add the following code
>>
>> from gnuradio import gr
>> p = gr.prefs()
>> p.set_string("audio","audio_module","portaudio")
>>
>> and close the editor. Basically, you're setting the configuration option
>> manually for the meantime.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 09.05.2016 04:38, Tony Richardson wrote:
>>
>> The command:
>>
>> gnuradio-config-info --prefsdir --sysconfdir
>>
>> returns
>>
>>   C:gr-buildsrc-stage3staged_installReleaseetc
>>   C:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
>>
>> The lack of path separators is troubling.  The fact these directories
>> don't exist on my machine (even with appropriate separators) is more
>> troubling.  I assume this is why config files in the installed etc
>> directory are not being read.  After using the Windows installer

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Geof Nieboer]

Tony, that's good news.

The nice thing is that the environment variables can generally be made as
relative paths, so I should be able include setting that automatically for
everyone as part of the msi.  The $home directory is probably the best
place as Windows doesn't want users changing files in the program files
directory.

Marcus,

The way the scripts works is the first you describe, it makes a "staged
install", during the build process, then Wix comes in and scans through
that directory to create the installation image, including Python.  The key
to making that work on the other end is the run_gr.bat file that used to
set that particular environment prior to running any scripts. It sets the
python path for instance... All based off the directory that the batch file
is in ($installer_dir/bin)

So any environment variables that gnuradio can use can be set there without
impacting ( or being impacted by) the result of the system.

Geof

On Monday, May 9, 2016, Tony Richardson  wrote:

> Thanks Marcus.
>
> I just set the environment variable that you mentioned in the run_gr.bat
> file that Geof mentioned and portaudio now works.  I realize it is not a
> clean solution, but it is a working one.  I am happy.
>
> Tony
>
>
>
>
>
> On Mon, May 9, 2016 at 9:42 AM, Marcus Müller  > wrote:
>
>> Hi Tony,
>>
>> to be honest, I'll be rewriting GNU Radio's slightly dated and slightly
>> ugly preference system, as it seems, so I'm not 100% giving up on this.
>> So, I hope the spirit of the workaround was clear to you: you can always
>> manually set this particular setting via python (instead of specifying it
>> in a configuration file).
>> The python module "detour" was just an attempt to make that a permanent
>> feature of the flow graph. Instead, I could have just asked you to add it
>> pretty far up in the generated top_block.py (or whatever your generated
>> python file is called). There's also another way of specifying such
>> settings – environment variables (which under windows are especially little
>> fun to set...).
>> You can (as documented in [1]) specify a setting as an environment
>> variable; in your case, something like
>>
>> GR_CONF_audio_audio_module = portaudio
>>
>> I know you can configure environment variables *somewhere  *in windows,
>> but I forget where – my Windows usage is just too rare.
>>
>> Best regards,
>> Marcus
>>
>> [1] http://gnuradio.org/doc/doxygen/page_prefs.html
>>
>>
>> On 09.05.2016 14:33, Tony Richardson wrote:
>>
>> There appear to be some problems with "python module"s in Windows GRC
>> too.  I get an error that the editor can't find a particular file.  If I
>> add the python block in GRC, then have it generate code and add the code to
>> the corresponding Python file from an external editor - I can then run the
>> top level Python file from a command prompt and it works!  (Appears to be
>> using portaudio).
>>
>> If I try to execute from GRC it replaces my Python source with a file
>> containing the line:
>>
>># this module will be imported in the into your flowgraph
>>
>> and will not run anymore.
>>
>> Thanks for your help, but I agree that it is time to give up.
>>
>> Tony
>>
>>
>> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller > > wrote:
>>
>>> Hi Tony,
>>>
>>> > The lack of path separators is troubling.
>>>
>>> I couldn't agree more. But since that just means that the separator
>>> get's "eaten" somewhere, and we don't know whether that happens when
>>> generating these paths or just when printing, I'm still full of hope…
>>>
>>> The fact these directories don't exist on my machine (even with
>>> appropriate separators) is more troubling.
>>>
>>> … my hopes being crushed.
>>>
>>> > Is there a way to override the default values?
>>>
>>> Yes, but not at runtime, I'm afraid: The "first" directory a program
>>> looks into for configuration has to be hard-coded somewhere, and in the
>>> case of GNU Radio, it's specified via the GR_PREFSDIR CMake Variable when
>>> building GNU Radio.
>>> That happens in the gnuradio/gnuradio/lib/constants.cc.in file, where
>>> CMake expands the @GR_PREFSDIR@ macro.  The actual setting of that
>>> variable happens in the main gnuradio/CMakeLists.txt, line 165
>>>
>>>set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH 
>>> "System configuration directory" FORCE)
>>>
>>> so we learn that CMAKE_INSTALL_PREFIX was set to
>>> C:gr-buildsrc-stage3staged_install, plus a few \, probably :D
>>>
>>> So that's essentially where I'd have to give up: That code was put there
>>> during build, and I can't change it later.
>>>
>>> What I'll probably do is a bug report about GNU Radio, upon finding the
>>> prefsdir path not to be a directory (in your case: not to exist at all)
>>> giving up and not even trying to read any other paths. I might fix that by
>>> allowing users to specify these directories as environment variables; that
>>> would make sense to me, but as it kind of changes "logical" API, I'd like
>>> to discuss this with a main

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Marcus Müller]

Hi Geof,

is there a chance to manually specify where the config files go in terms
environment variables? I.e., tell the installer to put what is in
PREFIX/etc into %APPDATA%?

Best regards,
Marcus


On 09.05.2016 17:37, Geof Nieboer wrote:
> Tony, that's good news.
>
> The nice thing is that the environment variables can generally be made
> as relative paths, so I should be able include setting that
> automatically for everyone as part of the msi.  The $home directory is
> probably the best place as Windows doesn't want users changing files
> in the program files directory.
>
> Marcus,
>
> The way the scripts works is the first you describe, it makes a
> "staged install", during the build process, then Wix comes in and
> scans through that directory to create the installation image,
> including Python.  The key to making that work on the other end is the
> run_gr.bat file that used to set that particular environment prior to
> running any scripts. It sets the python path for instance... All based
> off the directory that the batch file is in ($installer_dir/bin)
>
> So any environment variables that gnuradio can use can be set there
> without impacting ( or being impacted by) the result of the system.  
>
> Geof
>
> On Monday, May 9, 2016, Tony Richardson  > wrote:
>
> Thanks Marcus.
>
> I just set the environment variable that you mentioned in the
> run_gr.bat file that Geof mentioned and portaudio now works.  I
> realize it is not a clean solution, but it is a working one.  I am
> happy.
>
> Tony
>
>
>
>
>
> On Mon, May 9, 2016 at 9:42 AM, Marcus Müller
>  > wrote:
>
> Hi Tony,
>
> to be honest, I'll be rewriting GNU Radio's slightly dated and
> slightly ugly preference system, as it seems, so I'm not 100%
> giving up on this.
> So, I hope the spirit of the workaround was clear to you: you
> can always manually set this particular setting via python
> (instead of specifying it in a configuration file).
> The python module "detour" was just an attempt to make that a
> permanent feature of the flow graph. Instead, I could have
> just asked you to add it pretty far up in the generated
> top_block.py (or whatever your generated python file is
> called). There's also another way of specifying such settings
> – environment variables (which under windows are especially
> little fun to set...).
> You can (as documented in [1]) specify a setting as an
> environment variable; in your case, something like
>
> GR_CONF_audio_audio_module = portaudio
>
> I know you can configure environment variables /somewhere  /in
> windows, but I forget where – my Windows usage is just too rare.
>
> Best regards,
> Marcus
>
> [1] http://gnuradio.org/doc/doxygen/page_prefs.html
>
>
> On 09.05.2016 14:33, Tony Richardson wrote:
>> There appear to be some problems with "python module"s in
>> Windows GRC too.  I get an error that the editor can't find a
>> particular file.  If I add the python block in GRC, then have
>> it generate code and add the code to the corresponding Python
>> file from an external editor - I can then run the top level
>> Python file from a command prompt and it works!  (Appears to
>> be using portaudio).
>>
>> If I try to execute from GRC it replaces my Python source
>> with a file containing the line:
>>
>># this module will be imported in the into your flowgraph
>>
>> and will not run anymore.
>>
>> Thanks for your help, but I agree that it is time to give up.
>>
>> Tony
>>
>>
>> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller
>> > >
>> wrote:
>>
>> Hi Tony,
>>
>> > The lack of path separators is troubling.
>>
>> I couldn't agree more. But since that just means that the
>> separator get's "eaten" somewhere, and we don't know
>> whether that happens when generating these paths or just
>> when printing, I'm still full of hope…
>>> The fact these directories don't exist on my machine
>>> (even with appropriate separators) is more troubling.  
>> … my hopes being crushed.
>>
>> > Is there a way to override the default values?
>>
>> Yes, but not at runtime, I'm afraid: The "first"
>> directory a program looks into for configuration has to
>> be hard-coded somewhere, and in the case of GNU Radio,
>> it's specified via the GR_PREFSDIR CMake Variable when
>> building GNU Radio.
>> That happens in the gnuradio/gnuradio/lib/constants.cc.in
>>  file, where CMake expands the
>> @GR_PREFSDIR@ macro.  

Re: [Discuss-gnuradio] Sigh - 16.04 build failure

[Martin Braun]

There was a bug (until May 1st) that would effectively disable running
make a second time (with makewidth==1). I think you're running a PyBOMBS
from before that (not that I'm saying you should have, this is not in
the latest release yet), but it would give some better error message
than this. Can you retry with a newer PyBOMBS please?

M

On 05/07/2016 02:47 PM, Mike Willis wrote:
> Why is it always so difficult? Assume something broken in latest Ubuntu LTS
> 
>  pybombs -vv install gnuradio > error.txt
> 
> 
> 
> ___
> 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] Fwd: Re: Sigh - 16.04 build failure

[Marcus Müller]

 Forwarded Message 
Subject:Re: [Discuss-gnuradio] Sigh - 16.04 build failure
Date:   Mon, 9 May 2016 18:36:09 +0100
From:   Mike 
To: marcus.muel...@ettus.com



CPPUNIT is installed but is it also one of the first things pybombs 
builds - is that a conflict perhaps?



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

Re: [Discuss-gnuradio] ORC support on armhf w/ embedded SDK

[Ben Hilburn]

I know everyone that has responded in this thread already knows this, but
just in case anyone following along doesn't know:

ORC (the Oil Runtime Compiler) is abandonware, at this point. The company
that developed it, EntropyWave, closed up a while ago. I seem to remember
ttsou talking to the founder who said that they were focusing on a new
venture called "Rdio" (https://en.wikipedia.org/wiki/Rdio), which was
recently acquired by Pandora.

Cheers,
Ben

On Wed, May 4, 2016 at 12:23 PM, Martin Braun 
wrote:

> We actually dropped ORC support in UHD for that reason, although the
> benefit for us was even smaller than for volk.
>
> M
> On 3 May 2016 10:25, "Tom Rondeau"  wrote:
>
>> On Tue, May 3, 2016 at 11:53 AM, Sean Nowlan  wrote:
>>
>>> Sorry, email confusion with IEEE email forwarding. Resending to hit
>>> discuss-gnuradio list.
>>>
>>> Ok, thanks. FYI, it looks like ORC 0.4.23 is being used in OpenEmbedded
>>> Jethro. This version incorporated the bugfix, so it could theoretically be
>>> enabled in meta-sdr's gnuradio build.
>>>
>>
>>
>> ORC is still left out of the VOLK/GNU Radio builds. Frankly, I don't
>> trust ORC both for bugs but more importantly for how long it took to get
>> this bug addressed. I don't find that it provides enough benefits to us to
>> worry about making it work.
>>
>> Tom
>>
>>
>>
>>
>>> On Tue, May 3, 2016 at 11:51 AM, Sean Nowlan  wrote:
>>>
 Ok, thanks. FYI, it looks like ORC 0.4.23 is being used in OpenEmbedded
 Jethro. This version incorporated the bugfix, so it could theoretically be
 enabled in meta-sdr's gnuradio build.

 Sean

 On Tue, May 3, 2016 at 11:39 AM, West, Nathan <
 n...@ostatemail.okstate.edu> wrote:

> ORC is still in VOLK, but it doesn't give you much.
>
> On Tue, May 3, 2016 at 11:32 AM, Philip Balister 
> wrote:
>
>> On 05/03/2016 10:47 AM, Sean Nowlan wrote:
>> > According to the wiki [1], ORC support was disabled on armhf due to
>> a bug,
>> > which has apparently since been resolved [2]. Was ORC support added
>> back
>> > for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the
>> wiki
>> > page just out of date?
>> >
>> > Thanks,
>> > Sean
>> >
>> > [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded
>> > [2] https://bugzilla.gnome.org/show_bug.cgi?id=727464
>> > [3] http://gnuradio.org/data/sdk/
>>
>> I feel like we've replaced all the places we used orc, so we
>> (uhd/gnuradio/volk) are not really using it anymore.
>>
>> It tends to show up in images, just that it may not be used by
>> gnuradio
>> and friends.
>>
>> Philip
>>
>> >
>> >
>> >
>> > ___
>> > 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
>>
>>
> ___
> 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] Run Gnu Radio after installation

[Ben Hilburn]

Hi Shahnaz -

Your message is a little confusing. Did you try to install GNU Radio both
through PyBOMBS as well as your package manager?

If you used PyBOMBS to install GNU Radio, you do not need to install it a
second time through your OS.

Cheers,
Ben

On Thu, May 5, 2016 at 1:54 PM, Shahnaz Shirazi 
wrote:

> Hi all,
>
> Last night I installed Gnu radio through Pybombs without any error.
> I can see all folder being build correctly and have all the required
> library.
> But some how when I try to run Gnu radio getting error
>
>
> sudo apt-get install gnuradioThe program 'gnuradio-companion' is currently
> not installed. You can install it by typing:shahnaz@ubuntu:~$
> gnuradio-companion
>
> as suggested in GitHub I created another folder to install the gnu radio
> other than install in on usr/local.
>
> I added below line to my bashrc but no success :
>
> export
> PYTHONPATH=$PYTHONPATH:/home/shahnaz/Work/lib/python2.7/dist-packages
>
> Do I need another Path set up for Pybombs ?
> not sure what I'm missing but after I run the command
>
> pybombs [-p myprefix] install gnuradio
>
> I didn't get any error and at the end it confirmed successful installation.
>
> Thanks in advance.
>
> Shahnaz
>
> ___
> 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] ORC support on armhf w/ embedded SDK

[Tom Tsou]

On Mon, May 9, 2016 at 11:47 AM, Ben Hilburn  wrote:
> ORC (the Oil Runtime Compiler) is abandonware, at this point. The company
> that developed it, EntropyWave, closed up a while ago. I seem to remember
> ttsou talking to the founder who said that they were focusing on a new
> venture called "Rdio" (https://en.wikipedia.org/wiki/Rdio), which was
> recently acquired by Pandora.

Not quite. Indeed, the ORC project creator, David Schleef, moved on to
the music streaming industry, and the Entropy Wave website appears to
no longer exist. The ORC compiler, though, lives on as part of the
GStreamer project and remains actively maintained.

https://gstreamer.freedesktop.org/projects/orc.html

  -TT

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

Re: [Discuss-gnuradio] ORC support on armhf w/ embedded SDK

[Ben Hilburn]

Oh good to know! I thought the whole thing had disappeared.

Thanks, Tom.

Cheers,
Ben

On Mon, May 9, 2016 at 3:07 PM, Tom Tsou  wrote:

> On Mon, May 9, 2016 at 11:47 AM, Ben Hilburn 
> wrote:
> > ORC (the Oil Runtime Compiler) is abandonware, at this point. The company
> > that developed it, EntropyWave, closed up a while ago. I seem to remember
> > ttsou talking to the founder who said that they were focusing on a new
> > venture called "Rdio" (https://en.wikipedia.org/wiki/Rdio), which was
> > recently acquired by Pandora.
>
> Not quite. Indeed, the ORC project creator, David Schleef, moved on to
> the music streaming industry, and the Entropy Wave website appears to
> no longer exist. The ORC compiler, though, lives on as part of the
> GStreamer project and remains actively maintained.
>
> https://gstreamer.freedesktop.org/projects/orc.html
>
>   -TT
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I use formatter in QT GUI Label?

[Richard Bell]

Dan and Marcus (from another thread related to this),

I'm trying to do what you say, but I get an error when using
*"{0:.3e}".format* in the formatter field. The default value (0) is now
formatted properly but it won't ever update and in terminal I get the
following error

Exception in thread Thread-8:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
  File
"/home/rbell/Documents/pcodes/radio_devel/production/Stream/pcodes_bpsk_stream_FEC_complexDecoder_loopback.py",
line 1704, in _ber_probe
self.set_ber(val)
  File
"/home/rbell/Documents/pcodes/radio_devel/production/Stream/pcodes_bpsk_stream_FEC_complexDecoder_loopback.py",
line 2043, in set_ber

self.set_variable_qtgui_label_0(self._variable_qtgui_label_0_formatter(self.ber))
  File
"/home/rbell/Documents/pcodes/radio_devel/production/Stream/pcodes_bpsk_stream_FEC_complexDecoder_loopback.py",
line 2106, in set_variable_qtgui_label_0
Qt.QMetaObject.invokeMethod(self._variable_qtgui_label_0_label,
"setText", Qt.Q_ARG("QString",
eng_notation.num_to_str(self.variable_qtgui_label_0)))
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/eng_notation.py",
line 41, in num_to_str
m = abs(n)
TypeError: bad operand type for abs(): 'str'

I also get this error whenever I double click the QT GUI Label in question:

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Param.py",
line 72, in _update_gui
Utils.parse_template(TIP_MARKUP_TMPL, param=self.param).strip(),
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Utils.py",
line 121, in __call__
return str(template(namespaces=kwargs))
  File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005,
in __str__
rc = getattr(self, mainMethName)()
  File "cheetah_DynamicallyCompiledCheetahTemplate_1462212927_77_69202.py",
line 130, in respond
  File "cheetah_DynamicallyCompiledCheetahTemplate_1462212927_77_69202.py",
line 87, in truncate
IndexError: tuple index out of range

Am I doing something wrong?

Rich




On Fri, May 6, 2016 at 5:54 PM, Dan CaJacob  wrote:

> I am not sure about this, but you may try the standard python formatters.
> See https://docs.python.org/2/library/string.html
>
> On Fri, May 6, 2016 at 5:13 PM Richard Bell 
> wrote:
>
>> I am displaying a number using QT GUI Label in GRC like this
>>
>> 20.6u
>>
>> when I want it to display like this
>>
>> 20.6e-6 or 20.6x10-6, something along these lines.
>>
>> What do I put in the formatter section to make this happen?
>>
>> Rich
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> --
> Very Respectfully,
>
> Dan CaJacob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Sigh - 16.04 build failure

[Martin Braun]

Hi Mike,

I'd really like to get 16.04 support stable for the upcoming PyBOMBS
2.1.0 release. Thanks for testing newest code and all -- now we just
need to figure out what's actually not working :) It might be PyBOMBS
code *or* the recipes. I appreciate any logs!

Cheers,
M

On 05/09/2016 10:54 AM, Mike wrote:
> Unfortunately, I had thought of that and had updated pybombs. I did a
> rebuild just now -same result. I have now uninstalled libcppunit and
> repeated. Crashed again. I am trying again with more verbosity
> 
> 
> I can imagine the only way to fix this might be to start from scratch
> with a complete reinstall on ubuntu, but that would break everything else.
> 
> Mike


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

[Discuss-gnuradio] Fwd: Re: Sigh - 16.04 build failure

[Mike]

Found it ! I discovered a duplicate set of headers in /usr/local/include 
and /usr/include, fixing this didn't fix the problem.


After several hours wondering what was wrong with the headers I found 
there were two versions of libcppunit. This must have been a leftover of 
the upgrade to 16.04 as it should surely have been deleted when replaced 
by the updated version.


The older libcppunit-1.12 in /usr/lib/ and the newer, libcppunit-1.13 
was in /usr/lib/x86_64-linux-gnu/ - why in different directory I have no 
idea.


So the right headers were there but the wrong library was being selected 
which is why it failed to build.


I deleted the older version and build progressed.

So what else has the version upgrade left lurking?

Mike





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

Re: [Discuss-gnuradio] Fwd: Re: Sigh - 16.04 build failure

[Martin Braun]

Cool!

Can you keep us updated here if there were any other PyBOMBS-related
issues with 16.04? https://github.com/gnuradio/pybombs/issues is a good
place to jot those down, too.

Thanks,
Martin

On 05/09/2016 02:28 PM, Mike wrote:
> Found it ! I discovered a duplicate set of headers in /usr/local/include
> and /usr/include, fixing this didn't fix the problem.
> 
> After several hours wondering what was wrong with the headers I found
> there were two versions of libcppunit. This must have been a leftover of
> the upgrade to 16.04 as it should surely have been deleted when replaced
> by the updated version.
> 
> The older libcppunit-1.12 in /usr/lib/ and the newer, libcppunit-1.13
> was in /usr/lib/x86_64-linux-gnu/ - why in different directory I have no
> idea.
> 
> So the right headers were there but the wrong library was being selected
> which is why it failed to build.
> 
> I deleted the older version and build progressed.
> 
> So what else has the version upgrade left lurking?
> 
> Mike
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] Fwd: Re: Sigh - 16.04 build failure

[Marcus Müller]

As this is a relatively new option, it only works with the very latest PyBOMBS. 
Follow Martin's general advice of getting the newest version of it.

Best regards,
Marcus

Am 9. Mai 2016 20:26:22 MESZ, schrieb Mike :
>Starting again with a clean install of pybombs
>
>Why does this command not work by the way - I found a bug in the 
>documentation.
>
>|pybombs prefix init /path/to/prefix -a myprefix -R gnuradio-default 
>There is no -R option. |

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Re: Sigh - 16.04 build failure

[Ben Hilburn]

Hey Mike -

Quick question:

On Mon, May 9, 2016 at 5:28 PM, Mike  wrote:

> Found it ! I discovered a duplicate set of headers in /usr/local/include
> and /usr/include, fixing this didn't fix the problem.
>
> After several hours wondering what was wrong with the headers I found
> there were two versions of libcppunit. This must have been a leftover of
> the upgrade to 16.04 as it should surely have been deleted when replaced by
> the updated version.
>

Just to clarify, did you install cppunit through Ubuntu's package
management in a previous version of Ubuntu, and then update Ubuntu to
16.04, or did you install it using PyBOMBS in a previous Ubuntu install and
then update to 16.04?

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

Re: [Discuss-gnuradio] Fwd: Re: Sigh - 16.04 build failure

[West, Nathan]

On Mon, May 9, 2016 at 5:28 PM, Mike  wrote:

> Found it ! I discovered a duplicate set of headers in /usr/local/include
> and /usr/include, fixing this didn't fix the problem.
>
> After several hours wondering what was wrong with the headers I found
> there were two versions of libcppunit. This must have been a leftover of
> the upgrade to 16.04 as it should surely have been deleted when replaced by
> the updated version.
>
> The older libcppunit-1.12 in /usr/lib/ and the newer, libcppunit-1.13 was
> in /usr/lib/x86_64-linux-gnu/ - why in different directory I have no idea.


Is this three different versions of libcppunit?

Worth pointing out that the Ubuntu changelog (
http://changelogs.ubuntu.com/changelogs/pool/universe/c/cppunit/cppunit_1.13.2-2.1/changelog)
has a change of starting multi-arch installs from Sept 2012. The multi-arch
install is the different directory that you have no idea about and it helps
keep multi-arch and cross compiling sane.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Help in FEC example + ofdm modulation

[Jose Perez]

Hello colleagues,

I need some help! I am studying the FEC examples and for it I am using the
"fecapi_tagged_encoders.grc".
I can understand this example but I have problems when I try to simulate
some modulation and transmission. I don't receive any information and this
is showed in reports panel.

Using Volk machine: avx_64_mmx
gr::log :INFO: controlport - Apache Thrift: -h ubuntu -p 9090
gr::log :FATAL: fec_tagged_decoder0 - Missing a required length tag on port
0 at item #0
thread[thread-per-block[11]: ]: Missing length
tag.

Please, someone could help me with it?
You can see my grc file attached

Thank you!

fecapi_tagged_decodersMEU.grc
  



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Help-in-FEC-example-ofdm-modulation-tp59969.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] Run Gnu Radio after installation

[Shahnaz Shirazi]

Hi Ben,

No I tried to install it only through Pybomb but got an error.
Wednesday I got it install without an error but for some reason I deleted
the linux image and tried to reinstall it on Thursday.
I keep getting an error as sounds like they have updated the pybomb source.

  InsecurePlatformWarning
PyBombs.Fetcher - ERROR - Unexpected error while fetching wget+
https://pkgconfig.freedesktop.org/releases/pkg-config-0.28.tar.gz.
PyBombs.Fetcher - ERROR - hostname 'pkgconfig.freedesktop.org' doesn't
match either of 'distributions.freedesktop.org', 'farsight.freedesktop.org',
'fontconfig.freedesktop.org', 'fontconfig.org', 'freedesktop.org', '
geoclue.freedesktop.org', 'secure.freedesktop.org', 'www.fontconfig.org', '
www.freedesktop.org'
PyBombs.Packager.source - ERROR - Problem occurred while building package
pkg-config:
Unable to fetch recipe pkg-config
PyBombs.install_manager - ERROR - Error installing package pkg-config.
Aborting.

I'm trying to check the older version source from git hub but couldn't
figure out how check out and git works together to get the same source that
I used last Wednesday night.

Thanks,
shahnaz

On Mon, May 9, 2016 at 11:51 AM, Ben Hilburn  wrote:

> Hi Shahnaz -
>
> Your message is a little confusing. Did you try to install GNU Radio both
> through PyBOMBS as well as your package manager?
>
> If you used PyBOMBS to install GNU Radio, you do not need to install it a
> second time through your OS.
>
> Cheers,
> Ben
>
> On Thu, May 5, 2016 at 1:54 PM, Shahnaz Shirazi 
> wrote:
>
>> Hi all,
>>
>> Last night I installed Gnu radio through Pybombs without any error.
>> I can see all folder being build correctly and have all the required
>> library.
>> But some how when I try to run Gnu radio getting error
>>
>>
>> sudo apt-get install gnuradioThe program 'gnuradio-companion' is
>> currently not installed. You can install it by typing:shahnaz@ubuntu:~$
>> gnuradio-companion
>>
>> as suggested in GitHub I created another folder to install the gnu radio
>> other than install in on usr/local.
>>
>> I added below line to my bashrc but no success :
>>
>> export
>> PYTHONPATH=$PYTHONPATH:/home/shahnaz/Work/lib/python2.7/dist-packages
>>
>> Do I need another Path set up for Pybombs ?
>> not sure what I'm missing but after I run the command
>>
>> pybombs [-p myprefix] install gnuradio
>>
>> I didn't get any error and at the end it confirmed successful
>> installation.
>>
>> Thanks in advance.
>>
>> Shahnaz
>>
>> ___
>> 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] Announcing NEWSDR on Thr/Fri June 2/3 (Updated)

[Neel Pandeya]

​
*
NEWSDR 2016

  New England Workshop on Software-Defined Radio

Sixth-Annual

 Workshops
  Thursday June 2
 6:00 PM - 9:00 PM

 Symposium
   Friday June 3
 8:00 AM - 4:00 PM

 Northeastern University (NEU)
  Boston, MA, USA

  http://www.sdr-boston.org/

  Free Registration

 Poster Submissions Accepted Until Friday May 15

*
 INVITATION TO PARTICIPATE

You are cordially invited to the 2016 New England Workshop on
Software Defined Radio (NEWSDR 2016), which is the sixth installment
of an annual series of symposium and workshop events organized by
the Boston SDR User Group (SDR-Boston).

This year, NEWSDR will be held at Northeastern University (NEU),
and consists of a day-long symposium on Friday, as well as several
hands-on workshops the evening before on Thursday. You are welcome
to attend either or both events, which are entirely free.

Attendance is typically about 100 people, and attendees are from
both academia and industry.

*
 WORKSHOPS

  THURSDAY JUNE 2
   18:00 to 21:00

 Forsyth Building
 ​70 Forsyth Street
 Room 236 and 237

  AGENDA

16:00 to 18:00  Early Sessions for Workshop Setup and Prerequisites

18:00 to 21:00  Workshop Events

Two workshops are being offered:

* "SDR Challenge – Identifying Mystery Waveform Using Simulink
  and RTL-SDR" by MathWorks (more details listed below)

* "Hands-On Tutorial on FPGA Computing for SDR with RFNoC"
  by Ettus Research (more details listed below)

MathWorks and Ettus Research will each run a workshop on the evening
before the main event. Workshops are technical, practical, hands-on
activities in a group setting. Specific topics and further details
about the workshops will be announced shortly. Attendance is free,
but advance registration is required. Free pizza and soda will be
provided.

*
 SYMPOSIUM

   FRIDAY JUNE 3
   08:00 to 16:00

   Raytheon Amphitheater
   Egan Research Center
   120 Forsyth Street

  AGENDA

08:00 to 08:30  Coffee and Light Refreshments

08:30 to 08:40  Welcome and Introduction

08:40 to 10:00  Sponsor Flash Talks (20 minutes each)

10:00 to 11:00  Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits and Demos

11:00 to 12:00  Invited Talk: Mr Richard Reinhart,
NASA Glenn Research Center

12:00 to 13:00  Lunch and Attendee Networking

13:00 to 14:00  Invited Talk: Dr Tommaso Melodia,
Northeastern University

14:00 to 15:00  Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits and Demos

15:00 to 16:00  Sponsor Short Course by Analog Devices

16:00 to 16:15  Closing Remarks

Plenary Speakers:
  *  Mr. Richard Reinhart, NASA Glenn Research Center
  *  Prof. Tommaso Melodia, Northeastern University

Technical Poster Presentations:
  *  Covering the recent work in SDR and cognitive radio technology
  *  Poster presentations are now being solicited
  *  See link at the bottom of this email to submit your abstract

Corporate Sponsors:
  *  Analog Devices
  *  Ettus Research / National Instruments
  *  MathWorks
  *  MediaTek Wireless

The symposium features plenary speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and workshops from the event sponsors, all focusing
on recent work in SDR and cognitive radio technology. Free breakfast,
lunch, and coffee will be provided. Attendance is free, but advance
registration is required.

The symposium provides an excellent networking opportunity and a
terrific venue to exchange thoughts and ideas with other people
working in the SDR space.

*
   WORKSHOP DESCRIPTION

SDR Challenge – Identifying Mystery
Waveform Using Simulink and RTL-SDR
   by MathWorks

During this evening event, the audience will be tasked with
identifying a “mystery waveform” that is being generated in their
vicinity. Using MATLAB/Simulink and the RTL-SDR platform, both of
which will be provided dur

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Geof Nieboer]

Yes, Wix is pretty flexible in that regard.

It looks like right now some config files are looking in the $HOME
directory and some are looking in the $APPDATA directory, so I think we
should examine thoroughly what is looking where and aim for consistency.

Geof


On Monday, May 9, 2016, Marcus Müller  wrote:

> Hi Geof,
>
> is there a chance to manually specify where the config files go in terms
> environment variables? I.e., tell the installer to put what is in
> PREFIX/etc into %APPDATA%?
>
> Best regards,
> Marcus
>
>
> On 09.05.2016 17:37, Geof Nieboer wrote:
>
> Tony, that's good news.
>
> The nice thing is that the environment variables can generally be made as
> relative paths, so I should be able include setting that automatically for
> everyone as part of the msi.  The $home directory is probably the best
> place as Windows doesn't want users changing files in the program files
> directory.
>
> Marcus,
>
> The way the scripts works is the first you describe, it makes a "staged
> install", during the build process, then Wix comes in and scans through
> that directory to create the installation image, including Python.  The key
> to making that work on the other end is the run_gr.bat file that used to
> set that particular environment prior to running any scripts. It sets the
> python path for instance... All based off the directory that the batch file
> is in ($installer_dir/bin)
>
> So any environment variables that gnuradio can use can be set there
> without impacting ( or being impacted by) the result of the system.
>
> Geof
>
> On Monday, May 9, 2016, Tony Richardson  wrote:
>
>> Thanks Marcus.
>>
>> I just set the environment variable that you mentioned in the run_gr.bat
>> file that Geof mentioned and portaudio now works.  I realize it is not a
>> clean solution, but it is a working one.  I am happy.
>>
>> Tony
>>
>>
>>
>>
>>
>> On Mon, May 9, 2016 at 9:42 AM, Marcus Müller 
>> wrote:
>>
>>> Hi Tony,
>>>
>>> to be honest, I'll be rewriting GNU Radio's slightly dated and slightly
>>> ugly preference system, as it seems, so I'm not 100% giving up on this.
>>> So, I hope the spirit of the workaround was clear to you: you can always
>>> manually set this particular setting via python (instead of specifying it
>>> in a configuration file).
>>> The python module "detour" was just an attempt to make that a permanent
>>> feature of the flow graph. Instead, I could have just asked you to add it
>>> pretty far up in the generated top_block.py (or whatever your generated
>>> python file is called). There's also another way of specifying such
>>> settings – environment variables (which under windows are especially little
>>> fun to set...).
>>> You can (as documented in [1]) specify a setting as an environment
>>> variable; in your case, something like
>>>
>>> GR_CONF_audio_audio_module = portaudio
>>>
>>> I know you can configure environment variables *somewhere  *in windows,
>>> but I forget where – my Windows usage is just too rare.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> [1] http://gnuradio.org/doc/doxygen/page_prefs.html
>>>
>>>
>>> On 09.05.2016 14:33, Tony Richardson wrote:
>>>
>>> There appear to be some problems with "python module"s in Windows GRC
>>> too.  I get an error that the editor can't find a particular file.  If I
>>> add the python block in GRC, then have it generate code and add the code to
>>> the corresponding Python file from an external editor - I can then run the
>>> top level Python file from a command prompt and it works!  (Appears to be
>>> using portaudio).
>>>
>>> If I try to execute from GRC it replaces my Python source with a file
>>> containing the line:
>>>
>>># this module will be imported in the into your flowgraph
>>>
>>> and will not run anymore.
>>>
>>> Thanks for your help, but I agree that it is time to give up.
>>>
>>> Tony
>>>
>>>
>>> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller 
>>> wrote:
>>>
 Hi Tony,

 > The lack of path separators is troubling.

 I couldn't agree more. But since that just means that the separator
 get's "eaten" somewhere, and we don't know whether that happens when
 generating these paths or just when printing, I'm still full of hope…

 The fact these directories don't exist on my machine (even with
 appropriate separators) is more troubling.

 … my hopes being crushed.

 > Is there a way to override the default values?

 Yes, but not at runtime, I'm afraid: The "first" directory a program
 looks into for configuration has to be hard-coded somewhere, and in the
 case of GNU Radio, it's specified via the GR_PREFSDIR CMake Variable when
 building GNU Radio.
 That happens in the gnuradio/gnuradio/lib/constants.cc.in file, where
 CMake expands the @GR_PREFSDIR@ macro.  The actual setting of that
 variable happens in the main gnuradio/CMakeLists.txt, line 165

set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH 
 "System

[Discuss-gnuradio] Upgrade pybombs to spesific time

[Shahnaz Shirazi]

Hi,

I'm trying to check out the pybomb code that I've used on May 4th,2016 from
git hub.
so currently can update to latest by below command :


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

but when trying to upgrade to sepcific time stamp it doesn't work.

sudo -H pip install --upgrade
git+https://github.com/gnuradio/pybombs.git@{2016-05-04
16:30:00}


can some one help me on that?

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