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,
Marcus
[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:
How are you determining that this is only occupying a single core?I suppose that something like that should be written in gnuradi-core.conf, but really nothing.
You are probably right, cause that file doesn't even exist. I looked at default gnuradio-core.conf in conf.d.
Where can I find which option should be added?
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:
My guess is that your ~/.gnuradio/config.conf specifies to use the single-threaded scheduler.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:
I use gnuradio 3.6.5.1. 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?
Best,
--
Nemanja Savić
_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Nemanja Savić
--
Nemanja Savić
_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
