[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Why aren't these streams synchronous? (was: No change

From: Marcus Müller
Subject: [Discuss-gnuradio] Why aren't these streams synchronous? (was: No change when set_processor affinity() is used)
Date: Tue, 12 May 2015 22:14:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

Hi Nemanja,
I took the liberty of changing the subject to reflect the new topic :)

You're right, the low pass filters that the firdes tool produces should have linear phase, meaning that their impulse response is symmetrical and they have a constant phase delay of half the filter length.

I don't really think your synchronization as it is broken, but your signals might be:
* you're doing a 27k-tap filter. That means you're summing up 27k floating point numbers when doing the convolution of signal and filter. This *might* be a bit harsh for the numerical accuracy that a single precision floating point number offers. IIRC, the general (un-hand-optimized) volk kernel doing this just takes a single accumulator variable and sums over all tap[k-n]*sample[n]; not the optimal thing when it comes to numerical stability. However, hopefully no longer streaks in the filter impulse response have the same sign -- thus minimizing these effects. I'd strongly recommend using gr_filter_design, and plotting your filter's impulse, and its frequency response. Do you really need a transition width that narrow, or a ripple that small, or a suppression that high? Can you not decimate after the band pass? Does it have to be a complex band pass, or are the requirements in the upper and lower transitions so different, that you gain significantly by doing a LPF and a HPF after another?

* You do complex2mag²->low pass->logarithm. I don't really think taking the logarithm of a negative number is a good idea, and unless you now your signal very well, I don't think you can avoid getting negative numbers out of that low pass [1].

Best regards,

[1] http://imgur.com/70feESf  (by the way, that example is a bit constructed, but it brings the point across; it especially applies to situations where your signal gets clipped and you're working close to nyquist)

On 05/12/2015 07:07 PM, Nemanja Savic wrote:
You are right, cause I was looking in a process manager and only one core was 100% busy, but since the middle filter had 37k taps it might be that the other two were starving a little bit.
BTW, in the shown flograph, I would like to have signal in upper and down paths synchronized, so I introduced delay of (N-1)/2, where N is the number of taps in the middle filter. However signals in the files are not synchronized. What could cause that?

On Tue, May 12, 2015 at 7:01 PM, Marcus D. Leech <address@hidden> wrote:
On 05/12/2015 12:52 PM, Nemanja Savic wrote:

You are probably right, cause that file doesn't even exist. I looked at default gnuradio-core.conf in conf.d.
I suppose that something like that should be written in gnuradi-core.conf, but really nothing.
Where can I find which option should be added?
How are you determining that this is only occupying a single core?

Are you running on a VM?   If so, how many cores does your VM simulate?

On Tue, May 12, 2015 at 6:33 PM, Marcus D. Leech <address@hidden> wrote:
On 05/12/2015 12:25 PM, Nemanja Savic wrote:
Hi all guys,

I have a flowgraph where I have three parallel paths for filtering signal stored in a file. Here the picture of my flowgraph:

Inline image 1

I use gnuradio When I run the script it uses only one processor, and since I have 4 cores, I would like to run every of the paths on another processor. For every filter I do set_processr_affinity[some number between 0 and ]. When I run the script nothing changes, it still runs on a single core. Am I missing something with set_processor_affinity method?


Nemanja Savić

Discuss-gnuradio mailing list
My guess is that your ~/.gnuradio/config.conf   specifies to use the single-threaded scheduler.

Nemanja Savić

Nemanja Savić

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]