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 dir
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,
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, bu
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 mailin
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
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 t
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?
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-co
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 messag
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
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 me
11 matches
Mail list logo
