discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?


From: Alexandru Csete
Subject: Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
Date: Sat, 14 Sep 2013 00:57:54 +0200

On Fri, Sep 13, 2013 at 10:53 PM, Brian Padalino <address@hidden> wrote:
> On Fri, Sep 13, 2013 at 3:58 PM, Alexandru Csete <address@hidden> wrote:
>> On Fri, Sep 13, 2013 at 3:53 PM, Brian Padalino <address@hidden> wrote:
>>> On Fri, Sep 13, 2013 at 2:19 AM, Ralph A. Schmid, dk5ras
>>> <address@hidden> wrote:
>>>> Hi,
>>>>
>>>> I am using bladeRF with gr-osmosdr, gnuradio 3.7 and gqrx, so far a fine
>>>> radio. One thing, when using gqrx...I am limited to USB2.0 at the moment, 
>>>> so
>>>> I use a sampling rate of 8 Ms/s, and in this mode I have big problems with
>>>> images from the neighbour frequencies that are still within the 26 MHz
>>>> bandwidth, or whatever the maximum BW is.
>>>>
>>>> Is there some command to set this bandwidth to a smaller value? I assume
>>>> that this would improve my RX experience a lot :) A quick look at osmocom
>>>> showed me nothing, but maybe I missed smth.
>>>
>>> The gr-osmosdr interface allows for a bandwidth setting to be changed here:
>>>
>>>   
>>> http://cgit.osmocom.org/gr-osmosdr/tree/lib/bladerf/bladerf_source_c.cc#n581
>>>
>>> The driver will figure out which bandwidth is closest to what you want
>>> with a minimum of 1.5MHz and a maximum of 28MHz for the low-pass
>>> filters.
>>>
>>> It will definitely make a world of difference by actually applying the
>>> LPF and removing the aliasing.
>>>
>>> As for official support for gqrx, it's next on our list.  We need to
>>> get on the gqrx mailing list and figure out what code we need to
>>> write.
>>>
>>
>> Actually, it was a deliberate choice not to have explicit support for
>> that API call since it seemed unnecessary. Wouldn't one always want to
>> use the narrowest analog bandwidth corresponding to a given sample
>> rate? If yes, the setting may as well happen as part of the sample
>> rate configuration and best handled at a layer that knows about the
>> specific device. Am I wrong?
>
> One may want to listen to an LTE signal that is 5MHz wide, but sample
> at the standard 30.72MHz sample rate.  In this case, I would think the
> LPF might want to be set smaller than 28MHz (maybe 8MHz?) but still
> sample at 30.72MHz?
>
> Maybe another case is wanting to see 5MHz worth of bandwidth, seeing a
> weak signal, move the weak signal into the LPF region, and tighten the
> filter such that you could increase the gain without clipping the ADC
> in case there is a near-by blocker?
>
> I agree you can shoot yourself in the foot very easily by separating
> the two of them and have lots of noise alias in, but keeping them
> separate, in my mind, is still a very reasonable thing to do.
>
> Maybe, for the case of gqrx, an option for gr-osmosdr at device
> opening (and passed to the constructor) is to have a bandwidth setting
> (auto or manual) that when put into auto mode will do as you suggest,
> and set the appropriate low pass filter bandwidth as well as warn if
> the sample rate is too low, and there will be aliasing due to the LPF
> not being tight enough?
>
> What are your thoughts?

Hi Brian,

I didn't think of these cases - they make sense.
I have added an option to set the bandwidth in the I/O configuration
dialog. It is available in the git repository. I could test it with
hackrf anbd I hope somebody else can test it with the bladerf.
Currently it does no checking - just passes the value directly to
gr-osmosdr.

Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]