> 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.
Awesome - I will stick with Xlating FIRs then. I will have to get smarter on how to use the FFT to do the frequency shifting. I checked out Mike's app, but I don't have 3.7 installed yet so I couldn't play around with it. > 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, > seehttp://gnuradio.squarespace.com/home/2013/2/7/block-core-affinity.html . I will give the block core affinity a try. I think what maybe happening is that 2 process heavy blocks are being scheduled for the same core. I have a 4 core machine and it is only hitting ~60% CPU utilization, but it stops/slows decoding the trunking stream while it is doing vocoder work. It doesn't seem to have a problem doing NBFM Demod and recording, so I think the additional processing requirements of decoding digital audio is the problem. The Performance Counters seem like a great approach. It should give me a better idea where all the cycles are going. The network source/sink approach also sounds like a good one. And I have a spare laptop... :) > Awesome project! Thanks! I am having way too much fun with a $20 dongle. GNURadio is awesome.
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
