On 08/21/2013 08:15 PM, Luke B wrote:
- What is the best approach performance wise for selecting multiple ~15khz channels from a 2mhz+ source block? Is it using a Xlating FIR Filter with a low-pass? Is it more efficient to use a SIN Sig source & Multiply Block with a low-pass FIR Filter? Is there a better way to extract a filter?
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.
- What is the best way to have different bunch of blocks processing each signal run independently and not block each other? I want to do this as a GR C++ program is there any way to run the signal source and chanelizers as one thread and then have the different processing chains run as separate threads? Is there a way to put a queue or buffer inbetween blocks that would allow for a chain of blocks to be separated between threads?
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 .
Or am I better off doing the basic signal/channel processing for everything in a single process and then writing the results to a file and then having a process which goes through the files and does the more intensive vocoder work in non-real time?
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).
Any pointers or examples of how to do threading with GR C++ code would be really helpful. I am not sure of the best architectual approach.
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.
Background: I have taken the gr-smartnet code and done a skeleton implementation in C++. I want to process the digital trunking channel and then decode and record the digital audio from all of the different talk groups. Since it is trunked, channels will be randomly be turning on and off and talk groups will be switching from channels. It would be good to have a separate thread for the trunk decoding and the separate digital audio recorders. Ideally, I would like to be able to do this over 8 or 10Mhz using my HackRF. My code, which is working enough to decode the trunking channel, is here: https://github.com/robotastic/sdr
Awesome project! Happy hacking Marcus
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
