[Discuss-gnuradio] gqrx / gnuradio / BladeRF
Hi, Not exactly the perfect list for it, but as the specialists are all here in this list, it somehow should fit :) When using gqrx with the BladeRF I observe that tuning takes "ages". Every entered or changed frequency digit takes almost one second to be accepted, and I mean to remember that directly out of gnuradio this is much faster, although usually I do there no live tuning, but sending the frequency to the unit just once, out of a block. When using the USRP1 with WBX or a RTL2832/E4000 receiver, tuning occurs without noticeable delay. Bug or feature? :-) With best regards Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Openlte-discuss] Error while building openLTE code on USRP
Dincer, I believe that you will need to add a resampler to the openLTE code in order to run on a USRP. I don't have a USRP myself, but I believe that they only allow sample rates that are integer divisions of 100Msps (except the USRP B200 series). In order to get a valid LTE sample rate (30.72, 15.36, 7.68, 3.84, or 1.92Msps), you will need to add a resampling block. As you mentioned, I am using the gr-osmosdr blocks to interface currently to rtl-sdr and hackRF. There is support in gr-osmosdr for USRP, but it will need to be handled in the flowgraph. Hope this helps, Ben On Mon, Sep 30, 2013 at 7:21 AM, Dincer Beken wrote: > Sorry but I think I mailed to early. > > ** ** > > On a normal gnuradio distribution from the build-gnuradio.py -m” code on > Fedora, I did not experience the problems while build and install. > > I am checking out the code right now.. > > ** ** > > Regarding OSMO and RTL-SDR, I did understand it like the libraries can > detect and work with USRP, so that’s probably clear, too. > > When using those libraries with USRP, are there any specific changes that > I should make for some blocks etc.? > > ** ** > > Regards, > > Dincer > > > > ** ** > > *Von:* discuss-gnuradio-bounces+dbeken=blackned...@gnu.org [mailto: > discuss-gnuradio-bounces+dbeken=blackned...@gnu.org] *Im Auftrag von *Dincer > Beken > *Gesendet:* Montag, 30. September 2013 13:42 > *An:* openlte-disc...@lists.sourceforge.net > *Cc:* Discuss-gnuradio@gnu.org > *Betreff:* [Discuss-gnuradio] Error while building openLTE code on USRP*** > * > > ** ** > > Hi all, > > ** ** > > I am new to Gnuradio and USRP. I want to try the openLTE Project on my > USRP N210. > > ** ** > > During the cmake process I am getting the following errors: > > ** ** > > CMake Warning at CMakeLists.txt:92 (find_package): Could not find a > configuration file for package "Gnuradio" that is compatible with requested > version "3.7.0". > > The following configuration files were considered but not accepted: > > /usr/local/lib/cmake/gnuradio/GnuradioConfig.cmake, version: 3.8.git.0 > > ** ** > > ** ** > > Also since I am not using one of the following devices: > > I also get : > > ** ** > > -- checking for module 'gnuradio-osmosdr' -- package 'gnuradio-osmosdr' > not found -- Could NOT find GNURADIO_OSMOSDR (missing: > GNURADIO_OSMOSDR_LIBRARIES GNURADIO_OSMOSDR_INCLUDE_DIRS) -- checking for > module 'librtlsdr' -- package 'librtlsdr' not found -- Could NOT find > RTLSDR (missing: RTLSDR_LIBRARIES RTLSDR_INCLUDE_DIRS) -- checking for > module 'libhackrf' -- package 'libhackrf' not found -- Could NOT find > HACKRF (missing: HACKRF_LIBRARIES HACKRF_INCLUDE_DIRS) -- checking for > module 'fftw3f >= 3.0' -- found fftw3f , version 3.3 -- Found FFTW3F: > /usr/lib/libfftw3f.so CMake Error at CMakeLists.txt:99 (message): GNURadio > required to compile openLTE > > ** ** > > ** ** > > ** ** > > After that, I changed in the cmake file the required Gnuradio Version > manually to 3.8. Now I am getting only the OSMO / RTL errors: > > ** ** > > **· **-- checking for module 'gnuradio-osmosdr' -- package > 'gnuradio-osmosdr' not found -- Could NOT find GNURADIO_OSMOSDR (missing: > GNURADIO_OSMOSDR_LIBRARIES GNURADIO_OSMOSDR_INCLUDE_DIRS) -- checking for > module 'librtlsdr' -- package 'librtlsdr' not found -- Could NOT find > RTLSDR (missing: RTLSDR_LIBRARIES RTLSDR_INCLUDE_DIRS) -- checking for > module 'libhackrf' -- package 'libhackrf' not found -- Could NOT find > HACKRF (missing: HACKRF_LIBRARIES HACKRF_INCLUDE_DIRS) CMake Error at > CMakeLists.txt:103 (message): GNURadio Osmosdr required to compile openLTE ( > http://sdr.osmocom.org/trac/wiki/GrOsmoSDR) > > ** ** > > ** ** > > From the discuss Forum of gnuradio, I read that it is possible to run it > with USRP (USRP2) > > ** ** > > https://www.ruby-forum.com/topic/4169390#new > > ** ** > > ** ** > > How can I ignore those libraries or replace them? > > And can I use this code on the USRP? > > ** ** > > Regards, > > Dincer > > ** ** > > ** ** > > Mit freundlichen Grüßen, > > Dincer Beken > > ** ** > > e-mail: dbe...@blackned.de > tel.: +49 833199596-26 > > > [image: cid:image001.png@01CD3E54.B249FA20] > > * > blackned gmbh* · www.blackned.de > zentrale: dorfstrasse 3 · 88416 erlenmoos > niederlassung: am hartholz 21 · 82239 alling > > > > geschäftsführer: timo haas · josef stadler · hrb ulm 724147 > > > > > > Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten > Adressaten bestimmt. > > Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen > Vertreter sein sollten, > > bitten wir Sie, sich in diesem Falle umgehend mit dem Absender der E-Mail > in Verbindung > > zu setzen und diese Daten von Ihrem Computer zu löschen. Bitte beachten > Sie, dass jede > > Form von Veröffentlichung, Vervielfältigung oder Weitergabe des Inha
Re: [Discuss-gnuradio] gqrx / gnuradio / BladeRF
Hi Ralph, I've noticed that as well, and we need to fix it. I believe it's a bug. Not sure if it's in libbladeRF or gr-osmosdr, but we're on it. Sorry for the inconvenience. Brian On Tue, Oct 1, 2013 at 3:14 AM, Ralph A. Schmid, dk5ras wrote: > Hi, > > Not exactly the perfect list for it, but as the specialists are all here in > this list, it somehow should fit :) > > When using gqrx with the BladeRF I observe that tuning takes "ages". Every > entered or changed frequency digit takes almost one second to be accepted, > and I mean to remember that directly out of gnuradio this is much faster, > although usually I do there no live tuning, but sending the frequency to the > unit just once, out of a block. When using the USRP1 with WBX or a > RTL2832/E4000 receiver, tuning occurs without noticeable delay. > > Bug or feature? :-) > > With best regards > > Ralph. > > > > ___ > 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] gqrx / gnuradio / BladeRF
Hi, > Hi Ralph, > > I've noticed that as well, and we need to fix it. I believe it's a > bug. Not sure if it's in libbladeRF or gr-osmosdr, but we're on it. OK, great to hear. > Sorry for the inconvenience. Huh?! Early adopters we are, guess this is normal :-) Is there are dedicated mailing list for BladeRF? The forum is so inconvenient... Or should we keep it here? > Brian Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] wxgui issue with Windows version of GR-companion
Our build system is having issues with the GNU Radio Windows installers. We're currently working on a solution. On Sun, Sep 29, 2013 at 5:05 PM, Rasz wrote: > Same problem here, fresh install yesterday. > Examples loaded from > C:\Program Files (x86)\gnuradio\share\gnuradio\examples > work fine > anything from the desktop (including same examples) gives ImportError: > No module named wxgui_swig > > > -- > Who logs in to gdm? Not I, said the duck. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Nicholas Corgan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Openlte-discuss] Error while building openLTE code on USRP
Hi Ben,
thank you for your answer.
My previous question was bit strange.
There are to functions of you, once the dl_file_scan and once the only dl_scan
function.
I did undertood that the dl_file_scan function kinda works with USRP, but I was
not sure about the dl_scan function.
I read here that dl_scan does not support USRP:
http://sourceforge.net/p/openlte/mailman/message/30559702/
Is it still valid: Does the dl_scan function still not suppoert USRP?
OR can we by adding the resampler block run it?
When I did run the dl_scan function, it (probably the osmo code) recognized the
USRP2/N-SERIES device and got overflow alerts ("D").
I don't undertand, if that means that the dl_scan function works with the
USRP2/N but needs some resampling?
So from your mail, I thought first the addition of the "resampler" is only
valid for the dl_file_scan function, till I managed to run the dl_scan,
thatswhy I am confused.
Lastly, (this is probably my job).
I don't know if one can create from your source files grc flowcharts. I looking
for that right now. Then, it would be "easy" to add a resampling block to your
code.
If not, could you also please give a hint about how it can be done in your
source code?
Regards, Dincer
Von: Ben Wojtowicz [mailto:bwojt...@gmail.com]
Gesendet: Dienstag, 1. Oktober 2013 14:47
An: Dincer Beken
Cc: openlte-disc...@lists.sourceforge.net; Discuss-gnuradio@gnu.org
Betreff: Re: [Openlte-discuss] Error while building openLTE code on USRP
Dincer,
I believe that you will need to add a resampler to the openLTE code in order to
run on a USRP. I don't have a USRP myself, but I believe that they only allow
sample rates that are integer divisions of 100Msps (except the USRP B200
series). In order to get a valid LTE sample rate (30.72, 15.36, 7.68, 3.84, or
1.92Msps), you will need to add a resampling block.
As you mentioned, I am using the gr-osmosdr blocks to interface currently to
rtl-sdr and hackRF. There is support in gr-osmosdr for USRP, but it will need
to be handled in the flowgraph.
Hope this helps,
Ben
On Mon, Sep 30, 2013 at 7:21 AM, Dincer Beken
mailto:dbe...@blackned.de>> wrote:
Sorry but I think I mailed to early.
On a normal gnuradio distribution from the build-gnuradio.py -m" code on
Fedora, I did not experience the problems while build and install.
I am checking out the code right now..
Regarding OSMO and RTL-SDR, I did understand it like the libraries can detect
and work with USRP, so that's probably clear, too.
When using those libraries with USRP, are there any specific changes that I
should make for some blocks etc.?
Regards,
Dincer
Von:
discuss-gnuradio-bounces+dbeken=blackned...@gnu.org
[mailto:discuss-gnuradio-bounces+dbeken=blackned...@gnu.org]
Im Auftrag von Dincer Beken
Gesendet: Montag, 30. September 2013 13:42
An:
openlte-disc...@lists.sourceforge.net
Cc: Discuss-gnuradio@gnu.org
Betreff: [Discuss-gnuradio] Error while building openLTE code on USRP
Hi all,
I am new to Gnuradio and USRP. I want to try the openLTE Project on my USRP
N210.
During the cmake process I am getting the following errors:
CMake Warning at CMakeLists.txt:92 (find_package): Could not find a
configuration file for package "Gnuradio" that is compatible with requested
version "3.7.0".
The following configuration files were considered but not accepted:
/usr/local/lib/cmake/gnuradio/GnuradioConfig.cmake, version: 3.8.git.0
Also since I am not using one of the following devices:
I also get :
-- checking for module 'gnuradio-osmosdr' -- package 'gnuradio-osmosdr' not
found -- Could NOT find GNURADIO_OSMOSDR (missing: GNURADIO_OSMOSDR_LIBRARIES
GNURADIO_OSMOSDR_INCLUDE_DIRS) -- checking for module 'librtlsdr' -- package
'librtlsdr' not found -- Could NOT find RTLSDR (missing: RTLSDR_LIBRARIES
RTLSDR_INCLUDE_DIRS) -- checking for module 'libhackrf' -- package 'libhackrf'
not found -- Could NOT find HACKRF (missing: HACKRF_LIBRARIES
HACKRF_INCLUDE_DIRS) -- checking for module 'fftw3f >= 3.0' -- found fftw3f ,
version 3.3 -- Found FFTW3F: /usr/lib/libfftw3f.so CMake Error at
CMakeLists.txt:99 (message): GNURadio required to compile openLTE
After that, I changed in the cmake file the required Gnuradio Version manually
to 3.8. Now I am getting only the OSMO / RTL errors:
* -- checking for module 'gnuradio-osmosdr' -- package
'gnuradio-osmosdr' not found -- Could NOT find GNURADIO_OSMOSDR (missing:
GNURADIO_OSMOSDR_LIBRARIES GNURADIO_OSMOSDR_INCLUDE_DIRS) -- checking for
module 'librtlsdr' -- package 'librtlsdr' not found -- Could NOT find RTLSDR
(missing: RTLSDR_LIBRARIES RTLSDR_INCLUDE_DIRS) -- checking for module
'libhackrf' -- package 'libhackrf' not found -- Could NOT find HACKRF (missing:
HACKRF_LIBRARIES HACKRF_INCLUDE_DIRS) CMake Error at CMakeLists.txt:103
Re: [Discuss-gnuradio] gqrx / gnuradio / BladeRF
On Tue, Oct 1, 2013 at 10:41 AM, Ralph A. Schmid, dk5ras wrote: > > Hi, > >> Hi Ralph, >> >> I've noticed that as well, and we need to fix it. I believe it's a >> bug. Not sure if it's in libbladeRF or gr-osmosdr, but we're on it. > > OK, great to hear. > >> Sorry for the inconvenience. > > Huh?! Early adopters we are, guess this is normal :-) > > Is there are dedicated mailing list for BladeRF? The forum is so > inconvenient... Or should we keep it here? There is an IRC channel on freenode, #bladerf, which has decent activity. No mailing list yet. I agree the forum is not ideal. Best bet is through IRC and/or using the issue tracker on github. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Segmentation fault issue with gr_hier_block2_detail::connect
Hello GNU-Radio list, I wonder why is my C++ code is thorwing a segmentation fault (core dumped), gdb outputs: Program received signal SIGSEGV, Segmentation fault. 0xb7b1b718 in gr_hier_block2_detail::connect(boost::shared_ptr, int, boost::shared_ptr, int) () from /usr/local/lib/libgnuradio-core-3.6.5.so.0.0.0 I confirm that the same line of code which is throwing that error is executed multiple (randomly) times before it came to that error. I can't figure out what is causing that and how to fix it ? All explanation are welcome. Regards, -- View this message in context: http://gnuradio.4.n7.nabble.com/Segmentation-fault-issue-with-gr-hier-block2-detail-connect-tp43894.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] Segmentation fault issue with gr_hier_block2_detail::connect
And when I run again sometimes it stops and throw another segfault in the same location but labeled: Program received signal SIGSEGV, Segmentation fault. 0xb7af75f3 in gr_flowgraph::check_dst_not_used(gr_endpoint const&) () from /usr/local/lib/libgnuradio-core-3.6.5.so.0.0.0 -- View this message in context: http://gnuradio.4.n7.nabble.com/Segmentation-fault-issue-with-gr-hier-block2-detail-connect-tp43894p43895.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] Segmentation fault issue with gr_hier_block2_detail::connect
Could you provide us with a backtrace (in GDB: "bt") and if possible with the code that you use to produce this error. Usually, connect does not cause segfaults, a problem arises if you a) connect a block that does not exist yet (eg. in its constructor) b) connect a block in multiple flowgraphs. Greetings, Marcus On 10/01/2013 08:18 PM, Naceur wrote: Hello GNU-Radio list, I wonder why is my C++ code is thorwing a segmentation fault (core dumped), gdb outputs: Program received signal SIGSEGV, Segmentation fault. 0xb7b1b718 in gr_hier_block2_detail::connect(boost::shared_ptr, int, boost::shared_ptr, int) () from /usr/local/lib/libgnuradio-core-3.6.5.so.0.0.0 I confirm that the same line of code which is throwing that error is executed multiple (randomly) times before it came to that error. I can't figure out what is causing that and how to fix it ? All explanation are welcome. Regards, -- View this message in context: http://gnuradio.4.n7.nabble.com/Segmentation-fault-issue-with-gr-hier-block2-detail-connect-tp43894.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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Segmentation fault issue with gr_hier_block2_detail::connect
Thank you Marcus for the reply, I just figured out where was the problem: I am TWICE instantiating an object (a shared pointer) outside an if loop and inside of it, And for the backtrace it gives me that ... in main (argc=, argv=) ... Actually I fixed the issue. Cheers -- View this message in context: http://gnuradio.4.n7.nabble.com/Segmentation-fault-issue-with-gr-hier-block2-detail-connect-tp43894p43897.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
