Re: [Discuss-gnuradio] Gr-Inspector Install error

2017-02-10 Thread Marcus Müller
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

Re: [Discuss-gnuradio] Pybombs problem installing gnuradio dependencies

2017-02-10 Thread EJ Kreinar
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

[Discuss-gnuradio] Pybombs problem installing gnuradio dependencies

2017-02-10 Thread EJ Kreinar
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

Re: [Discuss-gnuradio] fft_filter_ccc Output Buffer Size

2017-02-10 Thread Dave NotTelling
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

[Discuss-gnuradio] fft_filter_ccc Output Buffer Size

2017-02-10 Thread Dave NotTelling
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.

Re: [Discuss-gnuradio] Gr-Inspector Install error

2017-02-10 Thread Jacqueline . Walker
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

Re: [Discuss-gnuradio] intermittent pulse detection

2017-02-10 Thread Vitt Benv
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

Re: [Discuss-gnuradio] How to make USRPs transmit and receive within 1 millisecond?

2017-02-10 Thread Marcus Müller
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

[Discuss-gnuradio] How to make USRPs transmit and receive within 1 millisecond?

2017-02-10 Thread Amarja Vaidya
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.