Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 05/12/2015 12:25 PM, Nemanja S. wrote:
set_processr_affinity[some number between 0 and ]. When I run the
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
My guess is that your ~/.gnuradio/config.conf specifies to use the
single-threaded scheduler.
What Marcus said; GNU Radio 3.6 with its default scheduler, which is
aptly named thread-per-block scheduler, automatically runs every block
in its own thread, and by default (ie. unless you explicitely specify
affinity) lets the OS handle distribution to CPUs; that’s the reason GNU
Radio applications tend to scale very well on multiple CPUs, even if the
algorithms in the individual blocks are not heavily multithreaded.
Greetings,
Marcus
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 05/12/2015 12:52 PM, Nemanja S. 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?
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
If that file does not exist, GNU Radio 3.6.5 would definitely use the
thread-per-block scheduler; you can try
export GR_SCHEDULER=TPB
prior to executing your flow graph from the same shell.
In fact, looking at top_block_impl.cc:59 in 3.6.5.1, it seems the
scheduler selection isn’t read from a config file at all (which is a
bug, which I think someone might timely fix, it’s still there in
3.7…); if you want to know what your GNU Radio selects as a default
scheduler, do
export GR_SCHEDULER=“a room full of monkeys trying to act like managers”
python yourflowgraph.py
The default scheduler will be printed.
Best regards,
Marcus
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)