Hi Jacqueline,
this really is, by all symptoms, a problem of how files are installed,
not how things are built. Swig works well if the library from the
build/swig directory works!
So, I think we moved a bit forward here: since python finds the right
__init__.py (if I follow correctly), but fails
Hi again,
Looks like my pip install was out of date. Apologies for the extra noise-
hope it helps someone :)
EJ
On Fri, Feb 10, 2017 at 3:41 PM, EJ Kreinar wrote:
> Hi all,
>
> I'm not sure if I'm reporting on the same pybombs problem as others
> recently [1], but I just
Hi all,
I'm not sure if I'm reporting on the same pybombs problem as others
recently [1], but I just ran into a problem installing gnuradio
dependencies with pybombs...
Here's the situation: I have a docker image which is attempting to install
gnuradio via pybombs. I'm building pybombs from the
After some more research it seems that this is an issue of not having an
even multiple of input samples to taps. For others, here is where I found
the answer: http://www.dspguide.com/ch18/2.htm
On Fri, Feb 10, 2017 at 11:19 AM, Dave NotTelling
wrote:
> I am trying to use
I am trying to use the FFT filter in some c++ code and I'm having issues
with seg faulting. The code below will work, but only because the output
buffer is twice as large as the input buffer. It doesn't have to be twice
as large, but it does have to be some number larger than the input buffer.
Thanks Marcus,
I can see it makes no sense that adding lines to the init.py telling it to look
in the build directories fixes the problem and it's probably not a viable long
term solution.
I will continue investigating.
However, 'it' (python, the GRC) does go to the install tree i.e., to the
Hi Dirk,
in my experience SDR is a nice stuff but sometimes analog tech can help:
try to lower total NF using a tuned LNA in front of you receiver... RTL
dongles or other sampler are a bit deaf and noisy, and your signal seems
very feeble.
... my 2 eurocent... !
Victor
2017-02-10 0:01 GMT+01:00
Hi Amarja Vaidya,
first off: GNU Radio is massively multithreaded, so you mustn't just
look in the top_block.py main thread; at low rates, however, it's
totally correct that the flow graph will mostly idle, since GNU Radio
works in a manner where the sample sources fill the buffers they have as
Hello,
I am building a system using USRPs where 2 USRPs communicate with each
other by sharing some data. The system works, but not as quickly and
efficiently as I want.
I have 2 USRPs, say A and B. First, B sends some data to A. As soon as A
receives data, it responds by sending some data to B.