Hi Vanush, It uses the gr-osmosdr GRC block and the Funcube Dongle Pro+ is second in the list of compatible devices so yes it will work:
http://sdr.osmocom.org/trac/wiki/GrOsmoSDR However, In order to work using the 192KHz bandwidth of the Funcube Pro+ you will need to fiddle with the sample rates and make sure that they are something like the following: 1) samp_rate = 192e3 2) channel_samp_rate = (quad_samp_rate * 1) 3) quad_samp_rate = (audio_samp_rate * 1) 4) audio_samp_rate = (48e3) I'll update Scanoo to have an option in the GUI for the 'channel_samp_rate' and 'quad_samp_rate' multipliers for easy Funcube use and better flexibility. Thanks for asking the question! Regards, Mike -- Mike Jameson M0MIK BSc MIET Email: m...@scanoo.com Web: http://scanoo.com On Wed, Aug 21, 2013 at 11:40 PM, Vanush Vaswani <van...@gmail.com> wrote: > Mike, does this work with the Funcube Dongle Pro+? > > > > > On Thu, Aug 22, 2013 at 4:39 AM, Mike Jameson <m...@scanoo.com> wrote: > >> Hi Luke, >> >> I've found using the FFT blocks are the most cpu efficient way to extract >> a channel from the whole 20MHz of the HackRF. Have a look at my latest >> Scanoo release built in GRC which uses the 'Keep X in N' block to select >> the channel required. There's also a spectrum sense mode which locks on to >> the strongest signal within the 20MHz bandwidth if it is not in the blocked >> frequency list: >> >> https://github.com/m0mik/scanoo >> >> Cheers, >> >> Mike >> >> -- >> Mike Jameson M0MIK BSc MIET >> Email: m...@scanoo.com >> Web: http://scanoo.com >> >> >> On Wed, Aug 21, 2013 at 7:15 PM, Luke B <luk...@gmail.com> wrote: >> >>> I am working on a processing multiple signals using a single source >>> block. The background is below, but I had a couple of high level questions: >>> >>> - 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? >>> >>> - 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? >>> >>> 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? >>> >>> 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. >>> >>> >>> 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 >>> >>> Thanks! >>> >>> - Luke >>> >>> _______________________________________________ >>> 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 >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
