rtl-sdr analog bandwith

[Luigi Tarenga]

hi everybody,
I just updated my librtlsdr on linux, now I have installed v0.7 from https://github.com/librtlsdr/librtlsdr/
Still I'm a little confused on the use of analog bandwith setting, I see no difference in the waterfall/panadapter
if I use 0 (default bw) or set something like 0.5 Mhz...
Did you ever see some signal filtering playing with this setting on gqrx?

I ask because I'm not sure if I'm on track with latest software development or I'm using some obsolete component
that stop me from being able to set the analog filter bw in the tuner. My dongle is the rtl-sdr blog silver one (v2).

On arch linux now I have:
gnuradio-osmosdr 0.1.5git-1 (csete github fork)
gnuradio 3.7.10.1-2
gqrx 2.6-2
librtlsdr 1:v0.7.0-1 (github fork, substiture rtl-sdr-git 0.5.3)

thank you very much in advance
Luigi

[Alexandru Csete]

Hi Luigi,

If this function was added to librtlsdr after they forked it, then it
is probably not supported by gr-osmosdr.

Indeed, this seems to be the case, as I don't see any "bandwidth"
function in this file:
https://github.com/csete/gr-osmosdr-gqrx/blob/master/lib/rtl/rtl_source_c.cc

In other words, the glue between the gqrx widget and the librtlsdr
function is not present.


Alex

[Luigi Tarenga]

Il giorno lunedì 28 novembre 2016 16:11:49 UTC+1, Alexandru Csete ha scritto:

In other words, the glue between the gqrx widget and the librtlsdr
function is not present.


Alex

uhm... Still i see some reference in the gnuradio companion rtlsdr source block.
see even here:
http://cgit.osmocom.org/gr-osmosdr/tree/grc/gen_osmosdr_blocks.py
.... snip ....
Bandwidth:
Set the bandpass filter on the radio frontend. To use the default (automatic) bandwidth filter setting, this should be zero.
.... snip ....

maybe this means it's present in the python grc block but not in the c++ code?

kind regards
Luigi

[Alexandru Csete]

It's a little more complicated...

gr-osmosdr acts like a driver wrapper, so for each function it needs
to have a programming interface (the part that gqrx sees) and an
implementation in the backend which calls the corresponding
functionality in the driver library.

The interface always exists and is defined in the header file:
https://github.com/csete/gr-osmosdr-gqrx/blob/master/include/osmosdr/source.h

The gr-osmosdr library also provides a default implementation which
will call the corresponding function in the backend, if it exists:
https://github.com/csete/gr-osmosdr-gqrx/blob/master/lib/source_impl.cc#L834

But as you can see in
https://github.com/csete/gr-osmosdr-gqrx/blob/master/lib/rtl/rtl_source_c.cc

the rtlsdr backend in gr-osmosdr does not implement this function, so
it will do nothing.

Do you seen any effect when you use in python?

Alex

[Luigi Tarenga]

Il giorno lunedì 28 novembre 2016 16:59:30 UTC+1, Alexandru Csete ha scritto:

Do you seen any effect when you use in python?

Alex

Hi Alex,
I tried with gnuradio-companion that I suppose it's equivalent than coding in python.
I used the rtl-sdr source block and a frequency sink with different analog bandwidth
setting but I see no difference. Do you think there is any chance that asking upstream
to implement this feature will lead to something? gr-osmosdr development seems
stagnant....

Luigi
 

[Alexandru Csete]

On Tue, Nov 29, 2016 at 10:49 AM, Luigi Tarenga <luigi....@gmail.com> wrote:
> Il giorno lunedì 28 novembre 2016 16:59:30 UTC+1, Alexandru Csete ha
>>

>> Do you seen any effect when you use in python?
>

> Hi Alex,
> I tried with gnuradio-companion that I suppose it's equivalent than coding
> in python.
> I used the rtl-sdr source block and a frequency sink with different analog
> bandwidth
> setting but I see no difference. Do you think there is any chance that
> asking upstream
> to implement this feature will lead to something? gr-osmosdr development
> seems stagnant....

I can't comment on that.

We can try to test it on my fork which you are already using; however,
I am in the middle of moving right now and don't have much time to
work on these things.

Alex

[Luigi Tarenga]

Il giorno martedì 29 novembre 2016 14:07:23 UTC+1, Alexandru Csete ha scritto:

We can try to test it on my fork which you are already using; however,
I am in the middle of moving right now and don't have much time to
work on these things.

Alex

Thanks Alex,
you are always kind but don't worry. There is no real urge on this. It's only my
curiosity to try and experiment. I'm looking at the gr-osmocom driver following
your hints. If I come up with a usable patch I will let you know.
best regards
Luigi

[Luigi Tarenga]

Il giorno martedì 29 novembre 2016 14:24:01 UTC+1, Luigi Tarenga ha scritto:

Thanks Alex,
you are always kind but don't worry. There is no real urge on this. It's only my
curiosity to try and experiment. I'm looking at the gr-osmocom driver following
your hints. If I come up with a usable patch I will let you know.
best regards
Luigi

Hi Alex,
it seems like I have some news to share :)

this is the very idiot patch I prepared:

diff --git a/lib/rtl/rtl_source_c.cc b/lib/rtl/rtl_source_c.cc
index 93328b8..7d3c368 100644
--- a/lib/rtl/rtl_source_c.cc
+++ b/lib/rtl/rtl_source_c.cc
@@ -584,6 +584,17 @@ bool rtl_source_c::get_gain_mode( size_t chan )
   return _auto_gain;
 }
 
+/* luigi */
+double rtl_source_c::set_bandwidth( double bandwidth, size_t chan )
+{
+  if (_dev) {
+    std::cerr << "Setting tuner bandwidth to " << bandwidth << " Hz." << std::endl;
+    return (double)rtlsdr_set_tuner_bandwidth( _dev, (uint32_t)bandwidth);
+  }
+
+  return 0;
+}
+
 double rtl_source_c::set_gain( double gain, size_t chan )
 {
   osmosdr::gain_range_t rf_gains = rtl_source_c::get_gain_range( chan );
diff --git a/lib/rtl/rtl_source_c.h b/lib/rtl/rtl_source_c.h
index 76de400..89c4f79 100644
--- a/lib/rtl/rtl_source_c.h
+++ b/lib/rtl/rtl_source_c.h
@@ -101,6 +101,7 @@ public:
   osmosdr::gain_range_t get_gain_range( const std::string & name, size_t chan = 0 );
   bool set_gain_mode( bool automatic, size_t chan = 0 );
   bool get_gain_mode( size_t chan = 0 );
+  double set_bandwidth( double bandwidth, size_t chan = 0 );
   double set_gain( double gain, size_t chan = 0 );
   double set_gain( double gain, const std::string & name, size_t chan = 0 );
   double get_gain( size_t chan = 0 );


and this is what it does:
with bandwidth 0 (default):

and this is with filter set to 0.5 Mhz:

I have to study a little to understand if the filter is symmetric around the IF center or not and if
the overall effect can be useful.
I will keep you up to date

bye!
Luigi

[Alexandru Csete]

Hi Luigi,

It looks promising! Keep us posted.

Alex

[Luigi Tarenga]

Hi Alex,
I'm still studying the algorithm that set the analog filter on the IF. the code is in file tuner_r82xx.c of librtlsdr.
I almost understood it all but I still want to make some test. I need to find where is set the default bandwidth.
I mean, by default it's set to 0 in the gui but it seems that this translate to the sample rate somewhere and
I see that this is the default filter bandwidth passed to librtlsdr. I ask to you because maybe it's set in gqrx...

The fact is that this should not be the default because it actually switch on the analog filter and change the
real IF frequency. The correct default should be 6 Mhz so the IF is set to 3.57. If you pass 2.4 Mhz to librtlsdr
the IF is changed to 1.815 Mhz. Sure everything works because librtlsdr seems to correctly compensate
everything and what you listen on gqrx is actually at the correct frequency but this is not the expected default
that you have prior of enabling the analog filter feature.

thank you in advance
Luigi  

[Luigi Tarenga]

Il giorno mercoledì 30 novembre 2016 21:20:29 UTC+1, Luigi Tarenga ha scritto:

I see that this is the default filter bandwidth passed to librtlsdr. I ask to you because maybe it's set in gqrx...

don't worry anymore, I found it. it's set in librtlsdr.c (librtlsdr)
int rtlsdr_set_and_get_tuner_bandwidth(rtlsdr_dev_t *dev, uint32_t bw, uint32_t *applied_bw, int apply_bw )
if bw is 0 it's set to sample_rate. It seems this was the default anyway even before I patched gr-osmosdr....
I believe there is some difference in what it's said (IF 3.57) on almost every forum and what librtlsdr actually does....

investigating....
Luigi