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, 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 <mle...@ripnet.com > <mailto:mle...@ripnet.com>> 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 >> <mle...@ripnet.com <mailto:mle...@ripnet.com>> 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 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 >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> My guess is that your ~/.gnuradio/config.conf specifies to >> use the single-threaded scheduler. >> >> >> >> >> >> -- >> Nemanja Savić > > > > > -- > Nemanja Savić > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
