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.
On Fri, Sep 13, 2013 at 8:19 AM, Ralph A. Schmid, dk5ras [email protected] wrote:
showed me nothing, but maybe I missed smth.
Ralph,
I think the hardware supports down to 1 MHz analog bandwidth and
gr-osmosdr also has support for that parameter, though I don’t know
whether the driver actually provides it. I can tell you for sure that
gqrx does not support it yet, but you can try it in the
gnuradio-companion.
Is there some command to set this bandwidth to a smaller value? I assume
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?
bandwidth, or whatever the maximum BW is.
with a minimum of 1.5MHz and a maximum of 28MHz for the low-pass
Actually, it was a deliberate choice not to have explicit support for
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.
On Fri, Sep 13, 2013 at 3:58 PM, Alexandru C. [email protected]
wrote:
filters.
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?
And as an addition, when trying to adjust the gain, I get these messages
on
the console output:
Invalid LNA gain requested: 3.48, setting to LNA_MAX (6dB)
Invalid LNA gain requested: 3.66, setting to LNA_MAX (6dB)
Invalid LNA gain requested: 3.96, setting to LNA_MAX (6dB)
Invalid LNA gain requested: 4.14, setting to LNA_MAX (6dB)
Invalid LNA gain requested: 4.2, setting to LNA_MAX (6dB)
Invalid LNA gain requested: 4.26, setting to LNA_MAX (6dB)
Invalid LNA gain requested: 4.32, setting to LNA_MAX (6dB)
Invalid LNA gain requested: 4.38, setting to LNA_MAX (6dB)
Invalid LNA gain requested: 4.44, setting to LNA_MAX (6dB)
Invalid LNA gain requested: 4.5, setting to LNA_MAX (6dB)
somebody
else can test it with the bladerf.
Currently it does no checking - just passes the value directly to
gr-osmosdr.
Just as an example, we have here three LTE carriers, and even with a few
cm of
wire as antenna it is almost impossible to determine the three signals
here. It all
mixes to a mush of signals. They are located as neighbor channels, 10 MHz
spacing (796/806/816 MHz), 9 MHz bandwidth each. Also the GSM bands are
full
of real and fake carriers what becomes visible when you have a look at the
band
ends and see signals “off limits” that simply are not there. With the
USRP1 / WBX
I only can see a part of this spectrum at a time, but almost without such
aliasing
artifacts.
Otherwise, I like the little thing, seems reasonably sensitive even at
high
frequencies (checked this with watching LTE2600 signals), just the lower
limit of
300 MHz is a bit ugly, down to 50 would be great Frequency is off 2ppm,
not
good enough for hopefully (soon?) coming openbts support, but I guess some
recalibration can fix it.
While writing this, I downloaded and compiled it. The filter itself works
great, I
can see it from the noise floor, just the images are not gone, seems that
the RX
simply is not as good as other SDRs. Anyway this is only a quick shot, I
will test it
more thoroughly these days, with different combinations of sampling rate
and
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
Great!
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.
Just as an example, we have here three LTE carriers, and even with a few
cm
of wire as antenna it is almost impossible to determine the three
signals
here. It all mixes to a mush of signals. They are located as neighbor
channels, 10 MHz spacing (796/806/816 MHz), 9 MHz bandwidth each. Also
the
GSM bands are full of real and fake carriers what becomes visible when
you
have a look at the band ends and see signals “off limits” that simply
are
not there. With the USRP1 / WBX I only can see a part of this spectrum
at a
time, but almost without such aliasing artifacts.
Otherwise, I like the little thing, seems reasonably sensitive even at
high
frequencies (checked this with watching LTE2600 signals), just the lower
limit of 300 MHz is a bit ugly, down to 50 would be great Frequency
is
off 2ppm, not good enough for hopefully (soon?) coming openbts support,
but
I guess some recalibration can fix it.
While writing this, I downloaded and compiled it. The filter itself
works
great, I can see it from the noise floor, just the images are not gone,
seems that the RX simply is not as good as other SDRs. Anyway this is
only a
quick shot, I will test it more thoroughly these days, with different
combinations of sampling rate and filter limits.
And as an addition, when trying to adjust the gain, I get these messages on
the console output:
Invalid LNA gain requested: 3.48, setting to LNA_MAX (6dB)
Probably gqrx or gr-osmosdr treats the gain as a continuous value even
though on the LMS it’s not, there is only a few discrete value.
They should be harmless warnings.
Probably gqrx or gr-osmosdr treats the gain as a continuous value even though
on the LMS it’s not, there is only a few discrete value.
They should be harmless warnings.
Yep, just wanted to mention it
I played a bit more, and I found that checking the iq balance option
makes things worse, not better. Maybe the real huge center DC peak is
too much? Without iq balance checked it looks so far OK, much better
than without the adjustable filter, and the previously mentioned
situation around 800 MHz is a bit unfair - I found that right below the
LTE band there is a strong 785 MHz DVB-T transmitter that mixes things
up a bit. Outside the GSM 900 and 1800 bands the spurs (spurs? Signals
almost as fat as the original ones!) seem gone with properly adjusted
filter.
Here some screenshots, taken with 10cm of wire directly plugged into the
bladeRF; sitting on my table
I played a bit more, and I found that checking the iq balance option makes
things worse, not better. Maybe the real huge center DC peak is too much?
The blind IQ estimation doesn’t always works, there is no “magic”
solution.
One of the case where it fails is if you’re tuned to the center of a
wideband signal …
It’s really more meant if you have narrow band signals to the left or
right of center (or both), but not with one big signal in the center.
A quick look at
Frequency is off 2ppm,