gnuradio3.10 gr-uhd: create new RFNoC OOT module
Hi, I previously worked with gnuradio3.8 where gr-ettus (grnocmodtool) was used to create GNURadio RFNoC OOT module. Now, for gnuradi3.10, it is no longer needed, and everything should be included in gr-uhd, but I do not find any references to create RFNoC OOT module in gnuradio3.10. There was a UHD RFNoC4 getting started guide showing how to build UHD C++ RFNoC module, but nothing mentions interface the OOT module to gnuradio. If I want to simply create a OOT RFNoC Gain module in GNURadio3.10, where can I find the reference to start with? Thanks, The information contained in this e-mail and any attachments from Radiance Technologies may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.
gr_modtool Won't Run (3.8.1.0; MacPorts)
I had this problem too. Gr-modtool uses the ‘click’ package - and it seems that the mac ports install of 3.8.1 does not install this dependency. I solved the problem by installing py37-click and py37-click-plugins with mac ports. I can’t recall if one is a dependency of the other but you need both I think. Kind Regards Tony Tyrwhitt-Drake
Installation of GNURadio on Centos 8
Hi Group... First, thanks for your efforts on the gnuradio open source project. I've read the wiki and I am impressed with the work that has been done. Great stuff! My problem...After some research and much effort, I was successful with getting the gnuradio-companion v3.7.x to run on centos 7. When I tried to follow the wiki tutorials, I noticed the tutorial reflects gnuradio v3.8.x. When I attempted to install and build gnuradio v3.8.x on centos 7, I got dependency problems with centos7. That led me to start over with centos 8. I now am not able to even get the binaries for gnuradio to install on centos 8. I have also tried building it on centos 8 and running into even more dependency problems. Question: Do you know if this is even possible at this time? Has anyone tried building gnuradio 3.7/3.8 on centos? Any advice would be much appreciated! -- Thanks, Tony
Re: [Discuss-gnuradio] Dependency Boost_FOUND = 0
Thank you Marcus, "apt-get build-dep gnuradio" did indeed install several other packages, but gnuradio-companion was excluded from compilation. I can repeat that compile attempt and report the cmake output/errors if needed, but I attempted the pybombs approach with some errors. If this forum allows attachments, the errors are in the attached file with CRLF in case anyone needs those. Even though libuhd-dev is installed I chose to use the source offering, so I'm not sure why that fails in the python script. On 09/30/2018 03:01 PM, Marcus Müller wrote: > Hi Tony, > > this shouldn't be happening. > Did you try `apt-get build-dep gnuradio` ? > If that doesn't help, can you share your complete cmake output with us? > > Best regards, > Marcus > On Wed, 2018-09-26 at 23:16 +, Tony wrote: >> Greetings, >> >> Using Debian 9 "Stretch" and the 20180925 github gnuradio, I've >> installed libboost-dev but am still achieving "Dependency Boost_FOUND >> = >> 0" errors on all components during Makefile-configuration with >> "cmake >> -DCMAKE_INSTALL_PREFIX=$HOME .. ". >> >> I also get the same problem after compiling >> https://sourceforge.net/projects/boost/ which reports: >> ... >> The Boost C++ Libraries were successfully built! >> The following directory should be added to compiler include paths: >> /home/me/src/boost_1_66_0 >> The following directory should be added to linker library paths: >> /home/me/src/boost_1_66_0/stage/lib >> >> ... and invoking "cmake -DCMAKE_INSTALL_PREFIX=$HOME >> -DBoost_INCUDE_DIR=/home/me/src/boost_1_66_0 >> -DBoost_LIBRARY_DIRS=/home/me/src/boost_1_66_0/stage/lib .." >> >> How to get it to recognize either the installed or the compiled >> Boost >> dependencies, please? >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ... [ 89%] Linking CXX shared module _trellis_swig0.so [ 89%] Built target _trellis_swig0 [ 89%] Built target pygen_gr_trellis_python_trellis_a71ba [ 89%] Built target pygen_gr_trellis_examples_python_c4b2e [ 89%] Built target gnuradio-uhd [ 89%] Built target tags_demo [ 89%] Built target _uhd_swig_doc_tag [ 89%] Built target uhd_swig_swig_doc [ 89%] Built target _uhd_swig_swig_tag [ 89%] Built target uhd_swig_gr_uhd_swig_5e3ce [ 89%] Built target pygen_gr_uhd_swig_5fcaa [ 89%] Building CXX object gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o /home/tross/prefix/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In function âPyObject* _wrap_time_spec_t_get_system_time(PyObject*, PyObject*)â: /home/tross/prefix/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:20194:16: error: âget_system_timeâ is not a member of âuhd::time_spec_tâ result = uhd::time_spec_t::get_system_time(); ^~~ /home/tross/prefix/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In function âPyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*, PyObject*, PyObject*)â: /home/tross/prefix/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:28428:15: error: âclass uhd::usrp::dboard_ifaceâ has no member named âset_gpio_debugâ; did you mean âset_gpio_ddrâ? (arg1)->set_gpio_debug(arg2,arg3); ^~ /home/tross/prefix/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In function âPyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*, PyObject*, PyObject*)â: /home/tross/prefix/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:29794:16: error: âclass uhd::usrp::dboard_ifaceâ has no member named âset_gpio_debugâ; did you mean âset_gpio_ddrâ? (*arg1)->set_gpio_debug(arg2,arg3); ^~ /home/tross/prefix/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In function âvoid init_uhd_swig()â: /home/tross/prefix/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:50154:91: error: âATR_REG_IDLEâ is not a member of âuhd::usrp::dboard_ifaceâ SWIG_Python_SetConstant(d, "dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int >(uhd::usrp::dboard_iface::ATR_REG_IDLE))); ^~~ /home/tross/prefix/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:50155:94: error: âATR_REG_TX_ONLYâ is not a member of âuhd::usrp::dboard_ifaceâ SWIG_Python_SetConstant(d, "dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int >(uhd::usrp::dboard_iface::ATR_REG_TX_ONLY)));
[Discuss-gnuradio] Dependency Boost_FOUND = 0
Greetings, Using Debian 9 "Stretch" and the 20180925 github gnuradio, I've installed libboost-dev but am still achieving "Dependency Boost_FOUND = 0" errors on all components during Makefile-configuration with "cmake -DCMAKE_INSTALL_PREFIX=$HOME .. ". I also get the same problem after compiling https://sourceforge.net/projects/boost/ which reports: ... The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: /home/me/src/boost_1_66_0 The following directory should be added to linker library paths: /home/me/src/boost_1_66_0/stage/lib ... and invoking "cmake -DCMAKE_INSTALL_PREFIX=$HOME -DBoost_INCUDE_DIR=/home/me/src/boost_1_66_0 -DBoost_LIBRARY_DIRS=/home/me/src/boost_1_66_0/stage/lib .." How to get it to recognize either the installed or the compiled Boost dependencies, please? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Windows 10 - RTL-SDR device not working
I am new to GNU Radio and SDR. I think this must be a simple problem, but I have tried to resolve this for a week and need some help. I have searched the gnu radio archives and have not been able to find a solution. I am trying to run the SDR course from Great Scott Gadgets: https://greatscottgadgets.com/sdr/ using soe inexpensive hardware for now. - I am running Windows 10 and have two new RTL2832U & R820T2-Based Software Defined Radios. - NooElec NESDR SMArTee Bundle - Premium RTL-SDR w/Integrated Bias Tee, Aluminum Enclosure, 0.5PPM TCXO, SMA Input & 3 Antennas. RTL2832U & R820T2-Based Software Defined Radio (SDR) - Adafruit: Software Defined Radio Receiver USB Stick - RTL2832 w/R820T - I have installed the correct drivers: WinUSB (v6.1.7600.16385) and have it successfully tuning in FM stations using SDRSharp v1.0.0.1667. - I installed gnuradio_3.7.11_win64.exe. - In GRC, I created a simple flowgraph with an RTL-SDR source and an WX GUI FFT Sink to just view part of the FM Spectrum. When I run the flowgraph, I get the following error mesage: - gr-osmosdr ae686c46 (0.1.5git) gnuradio 3.7.11 built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf airspy redpitaya Using device #0 Generic RTL2832U OEM usb_open error -12 FATAL: Failed to open rtlsdr device -- - I have tried rebooting and reinstalling gnuradio several times with the same results. - With the same laptop, I have tried running Pentoo Linux from a bootable USB drive, https://pentoo.ch/, and it has worked correctly, although I had trouble with GRC recognizing the sound card. - I have also created an Oracle VirtualBox VM running Mint18.3 SDR using https://t.co/Hmy3w7jm4f <https://www.youtube.com/redirect?q=https%3A%2F%2Ft.co%2FHmy3w7jm4f&redir_token=ih6l3oB1P0wUOfulCzUA560QrA18MTUzMTYyNjg0NUAxNTMxNTQwNDQ1&event=video_description&v=L0fSEbGEY-Q> and it works, but the performance is not great. - I would rather run this on Windows for now, if possible. I realize if I get further into this, I may need to eventually run Linux. Thanks for the help! Tony ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Portaudio Audio Source in Windows
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")
>>
>>
Re: [Discuss-gnuradio] Portaudio Audio Source in Windows
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 config
Re: [Discuss-gnuradio] Portaudio Audio Source in Windows
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/
Re: [Discuss-gnuradio] Portaudio Audio Source in Windows
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 --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 .gnuradio and config.conf. Boost might or might not fix that under
> windows. But it's probably OK.
>
> Best regards,
> Marcus
>
>
> On 07.05.2016 15:41, Marcus Müller wrote:
>
> The * is actually just an artifact of how that list is generated; it's
> written by CMake when gathering the enabled audio engines; When running
> cmake, you'll see something like
>
> -- ##
> -- # Gnuradio enabled components
> -- ##
> -- * python-support
> -- * testing-support
> [..]
> -- * gr-atsc
> -- * gr-audio
> -- * * alsa
> -- * * oss
> -- * * portaudio
> -- * gr-channels
> [...]
>
>
> And our beautiful hack to make alsa, oss, portaudio ... look like bullet
> points under gr-audio is actually to get these the name "* alsa", "* oss"
> and so on :D. That doesn't break automatic "grep-ability" to let scripts
> check for any of these, and if you had something like
>
> gnuradio-config-info --enabled-components|sed s'/;/\n/g'
>
> it'd give you the "original" tree-ish looking structure.
>
> so, for now, that's totally ok.
>
> Is there a way for me to figure out what configuration files are being
> read?
>
> Hm, logging. Witasec. I'll have to look this up; will do later.
>
> Best regards,
> Marcus
>
>
> On 06.05.2016 14:55, Tony Richardson wrote:
>
> I think I'm making progress with your help Marcus.
>
> The output of "gnuradio-config-info --enabled-components" is:
>
> python-support;testing-support;volk;doxygen;sphinx;gnuradio-runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;*
> portaudio;*
> windows;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq
>
> What does the '*' before portaudio mean?
>
> I thi
Re: [Discuss-gnuradio] Portaudio Audio Source in Windows
I think I'm making progress with your help Marcus. The output of "gnuradio-config-info --enabled-components" is: python-support;testing-support;volk;doxygen;sphinx;gnuradio-runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;* portaudio;* windows;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq What does the '*' before portaudio mean? I think you are also correct in that it appears my config.conf file is not being read. GRC created a ~/.gnuradio directory and populated it with a grc.conf file and prefs directory. I created a config.conf file in the same directory. Adding the [grc] stanza seems to have no effect. 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. Is there a way for me to figure out what configuration files are being read? Tony Richardson On Fri, May 6, 2016 at 3:14 AM, Marcus Müller wrote: > Huh, can you verify portaudio is in the output of "gnuradio-config-info > --enabled-components" ? > > Can you add another section, > > > [audio_portaudio] > verbose = true > > Just to verify: you're using the "[..]" section headers correctly, and the > rest of the conf file looks ungarbled, right? > > We might be encountering a case where the config file simply isn't read; > as a quick test: > Close all gnuradio-companions, add > > [grc] > canvas_default_size = 100,100 > > to that file, and open up the companion – your canvas size should now be > 100x100px. Is that the case? > > Best regards, > Marcus > > > On 06.05.2016 00:20, Tony Richardson wrote: > > Thanks, but I've tried that (setting "audio_module = portaudio"). It > doesn't appear to have the desired effect. > > Tony > > On Thu, May 5, 2016 at 4:26 PM, Marcus Müller > wrote: > >> Sorry, not currently running any Windows VM, but in the spirit of giving >> you the info you need as fast as possible: >> >> Quick lecture of the audio sink/source factory tells me that under >> windows, by default the windows audio architecture is used. >> So to use portaudio instead, you need to have a GNU Radio config file >> (under unixoids, that's ~/.gnuradio/config.conf), and add >> >> [audio] >> audio_module= portaudio >> >> >> Best regards, >> Marcus >> >> On 05.05.2016 22:59, Tony Richardson wrote: >> >> I'm using the pre-built Win64 binary of GNURadio listed on the >> gnuradio.org site. The portaudio library was included as part of the >> Win64 build, but I can't seem to figure out how to use it instead of the >> default windows audio. (I want an audio source and the windows audio >> source does not work.) I've tried putting "audio_module = portaudio" (and >> "audio_module = audio_portaudio") in the config.conf file, but when I run a >> simple flowgraph that includes an audio source and sink, I see: >> >> INFO: Audio source arch: windows >> INFO: Audio sink arch: windows >> >> in the console and there is no sound. I assume the lines above are >> telling me that the windows audio devices are being used and not the >> desired portaudio devices. I have tried leaving the device name in the >> audio source blank as well as trying "0" and "hw:0,0", but still see the >> messages above. Can someone tell me how to configure audio for portaudio >> or is it just not supported? >> >> Tony Richardson >> >> >> ___ >> 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] Portaudio Audio Source in Windows
Thanks, but I've tried that (setting "audio_module = portaudio"). It doesn't appear to have the desired effect. Tony On Thu, May 5, 2016 at 4:26 PM, Marcus Müller wrote: > Sorry, not currently running any Windows VM, but in the spirit of giving > you the info you need as fast as possible: > > Quick lecture of the audio sink/source factory tells me that under > windows, by default the windows audio architecture is used. > So to use portaudio instead, you need to have a GNU Radio config file > (under unixoids, that's ~/.gnuradio/config.conf), and add > > [audio] > audio_module= portaudio > > > Best regards, > Marcus > > On 05.05.2016 22:59, Tony Richardson wrote: > > I'm using the pre-built Win64 binary of GNURadio listed on the > gnuradio.org site. The portaudio library was included as part of the > Win64 build, but I can't seem to figure out how to use it instead of the > default windows audio. (I want an audio source and the windows audio > source does not work.) I've tried putting "audio_module = portaudio" (and > "audio_module = audio_portaudio") in the config.conf file, but when I run a > simple flowgraph that includes an audio source and sink, I see: > > INFO: Audio source arch: windows > INFO: Audio sink arch: windows > > in the console and there is no sound. I assume the lines above are > telling me that the windows audio devices are being used and not the > desired portaudio devices. I have tried leaving the device name in the > audio source blank as well as trying "0" and "hw:0,0", but still see the > messages above. Can someone tell me how to configure audio for portaudio > or is it just not supported? > > Tony Richardson > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Portaudio Audio Source in Windows
I'm using the pre-built Win64 binary of GNURadio listed on the gnuradio.org site. The portaudio library was included as part of the Win64 build, but I can't seem to figure out how to use it instead of the default windows audio. (I want an audio source and the windows audio source does not work.) I've tried putting "audio_module = portaudio" (and "audio_module = audio_portaudio") in the config.conf file, but when I run a simple flowgraph that includes an audio source and sink, I see: INFO: Audio source arch: windows INFO: Audio sink arch: windows in the console and there is no sound. I assume the lines above are telling me that the windows audio devices are being used and not the desired portaudio devices. I have tried leaving the device name in the audio source blank as well as trying "0" and "hw:0,0", but still see the messages above. Can someone tell me how to configure audio for portaudio or is it just not supported? Tony Richardson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Standalone USRP1 Operation
Hi 2009/4/24 : > >> An easier path would be to look small processor boards such as those >> that support embedded Linux. For instance the web page for the >> Gumstix Overo Earth says it has a "USB HS Host" and a micro SD slot. >> (Not micro SDHC - so you are limited to, I think, 4Gb cards.) >> See: >> http://gumstix.com/store/catalog/product_info.php?cPath=31&roducts_id=211 > > Thank you for your suggestion, but I'm looking for cheep and simple method to > load USRP firmware. First I think you should verify that the USRP cannot permanently store firmware in some way, maybe even contact Matt Ettus? Programming for USB Host is unfortunately not simple, as it needs a whole comms stack. It requires several months programming to get all the functionality, though you can probably skip some parts for your dedicated support for a single device. But take it from someone who has done this you will have problems, and sooner or later you will need to purchase or rent a USB Analyser to debug the comms. (This cost was something like $2 the last time I needed one!) I think approx $150 for a board that runs Linux and you can be confident will do the job is a bargain. ;-) Probably there are lots of suppliers of boards for embedded Linux, I only mentioned one brand because I have heard good comments about their products. If you still decide you want to build your own USB Host you should at least get Jan Axelson's "USB Complete" book, which covers many of the practicalities. If you can find it, the Mindshare book on USB System Architecture by Don Anderson is easier to read than the official standards at the USB Implementers Forum (www.usb.org). Regards, Tony ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Standalone USRP1 Operation
Hi I don't yet know a lot about the USRP, but I do know about USB. The short answer is that the PIC 18F4550 processor will not help. USB needs a "host" (typically a PC) that times & controls each data packet and a "device" to talk to. Optionally a hub is both a device and relay of timing & data to further devices. Both the PIC processor and the USRP are devices, and cannot talk to each other. Also the USRP documentation says it needs "USB2", which I think means it needs the "High Speed" data transfer of USB2. Whereas the PIC 18F4550 only supports the lower transfer speeds of USB1.1, and is USB2 compatible in the sense that it works with USB2 Hosts. Some of the 16-bit and 32-bit PIC processors have a USB Host port, or at least can operate a USB "On-The-Go" (OTG) port in host mode - but I'm not sure if they support "High Speed" (HS) mode, and you will need a lot of software to control the USB. An easier path would be to look small processor boards such as those that support embedded Linux. For instance the web page for the Gumstix Overo Earth says it has a "USB HS Host" and a micro SD slot. (Not micro SDHC - so you are limited to, I think, 4Gb cards.) See: http://gumstix.com/store/catalog/product_info.php?cPath=31&products_id=211 Cheers, Tony 2009/4/24 Firas A. : > > Hi, > > Has anyone tried to run USRP1 without PC? > > I have an application where a friend supported me with a standalone USRP > FPGA image. I used the PC only to load this image to the USRP using gnuradio > blocks/tools. After that I can plug-off (disconnect) the USB cable from the > PC and USRP continue to operate standalone. > > My question is, has anyone tried to load USRP FPGA image without a PC? For > example using a micro-controller (Like Microchip PIC 18F4550 which has USB > 2.0 port) with SD memory holding the image? > > What it takes/need to do so? > > > Best Regards, > > Firas > -- > View this message in context: > http://www.nabble.com/Standalone-USRP1-Operation-tp23210804p23210804.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] (no subject)
Hi Probably you will get more response if you give more details of what you want to do. There are RFID / NFC tags operating at various frequencies, and to a variety of standards. Each will tend to require different tx/rx modules, antennas, modulation/demodulation schemes. Also why are you trying to this with GNU radio? Standard RFID reader/writer hardware is a lot cheaper and, depending on what frequencies/standards you are interested in, a multi-standard reader could probably be built from scratch for $100 (US) of parts. Regards, Tony 2009/3/23 harshal jadhav > hi everybody.. > > i want to do a project on GNU RADIO based RFID reader . > i need information about any advancement has been done in this field and > what are the paths alongwith advancement is required. > > Regards, > Harshal Jadhav > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Details on USB buffer
The USRP C++ example program uses this code to move USRP USB data into a buffer: urx->read(&buf, bufsize, &overrun); If this line is called many times in a short period of time will the buffer have some of the data leftover from previous read(s)? Can I assume that the OS will not return the buffer until the next n bytes have been received? Tony ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Unable to install GNU radio with UBUNTU 7.1
I'm having trouble loading GNU Radio software on a PC running UBUNTU 7.1 and can't seem to get a clean install. apt-get update reports: E: Could not open lock file /var/lib/apt/lists/lock - open (13 Permission denied) E: Unable to lock the list directory After the install is complete programs like dial_tone.py run properly but usrp_benchmark.py reports: RuntimeError: can't open usrp1 ls -lR /dev/bus/usb | grep usrp shows crw-rw 1 root usrp 189, 8 2007-11-24 19:37 009 when the USRP is connected and plugged in. Can anyone advise me on this issue? Regards, Tony Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Can't find python-numpy-ext
The GNURadio installation instructions refers to program python-numpy-ext. When I try to install that program via sudo apt-get -y install python-numpy-ext the system reports E: Couldn't find package python-numpy-ext Can someone comment on the possible cause? Tony __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Real world NTSC capture files
Hi, Does anyone know where I might find some real-world NTSC data captures? I'm specifically looking for a capture with BTSC + SAP in the audio for software demodulation. Audio test tones are just too trivial to be useful for testing. Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to send USRP data to the terminal window
I'm operating GNU Radio 2.8 on Ubuntu 6.06 LTS and using USRP mostly with the DBSRX rev 2.1 daughterboard. Can someone comment on 2 questions.How can you display the raw or processed USRP I & Q data on the screen? I've done this by using something like this:...sink1 = gr.complex_to_float()sink2 = gr.file_sink(gr.sizeof_float,"/dev/tty")fg.connect(self,sink1,sink2)..but I'd like to refine the data output, time stamp it and only have it display based on one or more criterions. Is it reasonable to do this in Python or is sending the data to another process a better solution?What is the format of the USRP complex output and the FFT output? Is it documented somewhere?Many thanks to all that have worked on the GNU Radio project. I hope to become a contributing member as I gain more skill here.Tony B Yahoo! Sports Fantasy Football 06 - Go with the leader. Start your league today! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
