|Subject:||Re: [Discuss-gnuradio] Processing multiple signals off single source block|
|Date:||Thu, 22 Aug 2013 12:24:38 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8|
On 08/21/2013 08:15 PM, Luke B wrote:
Xlating FIRs just generate the sin internally and apply it themselves; they are mathematically equivalent to shifting your signal and filtering it afterwards.
You can, of course, use bandpasses, if you're after a specific sprectral shape. Try the gr_filter_design toolbox, it's even neater than doing your calculations in Matlab (or scipy).
However, as Mike already pointed out, depending on your signal and potential interferers of course, selection by trunkated fft is faster and as intuitive.
I'm not quite sure I understand your question correctly. GNU Radio has built-in concurrency for blocks.
Tom Rondeau has a blog entry on core affinity, see http://gnuradio.squarespace.com/home/2013/2/7/block-core-affinity.html .
Ok, this is another issue: If you think your computation is too heavy for your platform, then splitting it into an online and offline part might make sense. If you really want to find out what eats your cpu, try the helpful performance counters http://gnuradio.org/redmine/projects/gnuradio/wiki/performancecounters .
Since decoding voice is usually a process that has to happen only for one channel at a time, you might as well just save the input samples for later offline decoding, extract only one channel at a time online and decode that one for playback.
Although that might be wasteful on storage capacities (2Msam/s with 2*4B/sam=16MB/s), but it gives you the power to do the most amazing and computationally intensive filtering/equalizing/fec/... on your samples when you're not doing it in real time anyways.
Another well-tested trick: Network sinks/sources. Just use your rx machine to do the trunking, and if it has enough power left, select the right frequencies of each talk group by filter/fft, and send streams of samples for each group via network to your decoder machine(s).
Well, you can "multi-thread" your own block's work function, but I'd advise you not to do that unless you really know what your scheduler will do to you. Simply rely on GNU Radio to fully use up your available CPU power to schedule several blocks at once; you have enough of them.
|[Prev in Thread]||Current Thread||[Next in Thread]|