Update: RTL2832 re-written (better GRC block, librtl2832++) & works with OP25 digital radio!

Hi folks,

Firstly, thank you to those who have tested the initial release and have
been in touch with feedback - I really appreciate it.

I would like to share the completely re-written RTL2832 code in gr-baz
http://wiki.spench.net/wiki/gr-baz#rtl_source_c , which should now
support
all devices I can find with an E4000, FC0013 and now FC0012 tuner (if
there
are any missing, you can simply set the custom VID/PID in the GRC
RTL2832
Source block, or add just one line to an array in rtl2832.cc). This will
be
ported to the Windows plugin soon.

The RTL2832 Source block code itself is much tidier, and makes use of
(what
I submit for your consideration/experimentation as) ‘librtl2832++’ -
this is
a completely re-designed GNU Radio-independent C++ (OO) interface to the
hardware. The idea is to make it really easy to talk to the dongles. If
you
want to use it for something else, just copy out the ‘rtl2832-*’ files!
You
will find the main ‘demod’ class, and the 'tuner’s, all with (I hope) a
simple API.

The updated GRC Source block also exposes lots of new settings too
(including bandwidth, buffer settings, FIR coefficients, .).

Moreover, just to ensure that I hadn’t led people down the garden path
(since, let’s face it, it’s 8 bits, XO drifts like crazy, and wasn’t
designed for general-purpose SDR), I hooked it up to OP25
http://op25.osmocom.org/ (the open source P25 digital radio decoder)

and happily it works!

Check out the RTL2832+OP25+DES-OFB demonstration/RTL2832 update video:

In the process I also created two new GRC blocks (now in gr-baz, also in
the
video):

  1.   'OP25 Decoder' (float baseband in, audio out with optional
    

parameter for setting DES-OFB decryption key - this requires a patch
with
decryption support that I will release soon)

  1.   'Message Callback' sink whose input port accepts messages, and
    

calls the relevant GRC-generated code to update a GRC variable (i.e. you
can
have various blocks that output messages into a message queue, and these
will be picked up by this block and trigger a particular variable in
your
flowgraph to by updated automatically - e.g. you can change a tuning
offset
if a block detects a frequency error creeping in, and/or you can have
GUI
elements - text boxes/sliders/etc - controlled by arbitrary blocks if
their
value needs to be updated by a feedback mechanism)

Please note: RTL2832’s Source block now has Relative Gain enabled by
default, so valid gain values are in the range [0,1]. This means you
don’t
need to remember the absolute gain range for whichever tuner you have!

Also, there is a known issue that may occur while tuning. If you change
the
frequency too rapidly, a USB error may occur and require reconnection of
the
dongle (this has only ever happened to me though when there are sample
rate
mismatches in a flowgraph). Enforcing coarse-grained locking in the
source
block code does not solve this. The only obvious fix to me at this stage
is
rate-limiting tuning requests (I’m guessing perhaps the device wasn’t
designed to expect rapid re-tuning). Implementing async libusb control
transfers would also be nice!

Finally, I have found that on my Linux box, streaming performance isn’t
as
great as on Windows. By ‘performance’ I mean occasional degradation in
the
baseband signal (i.e. signal ‘jumps’, after AM or FM demod of a constant
tone, you would hear a ‘click’ discontinuity). I hope that’s not a
result of
an undiscovered bug, but I’ve been largely able to avoid these
discontinuities by selecting a modest sample rate (e.g. 1 Msps),
increasing
the transfer read length (you can do this easily in the GRC block) to
e.g.
256K (though this will increase delay in reflection of freq/gain changes
in
output signal due to longer buffer), and enabling real-time scheduling
(this
requires root).

If you get run-time complaints about it not finding certain libraries,
don’t
forget to run ‘sudo ldconfig’.

If you do try it out, please let me know how you go! I only have one
adapter
with the E4000, so I haven’t actually tested any others myself. Fingers
crossed!

Kind regards,

Balint @spenchdotnet http://twitter.com/spenchdotnet

Balint,

Thanks for your work on this. Yesterday I have been playing with my EzTV
666 and today I tried a Dexatek dongle using your latest code with
FC2580
tuner support.

If I try to run a simple src->fft flowgraph (attached) right after
plugging
the dongle in I get a bunch of errors, see atached fc2580-1.txt file. I
tried to capture a file using the latest rtl-sdr code from the osmocom
repository using the same frequency and sample and it worked. After that
I
can try the grc flowgraph using your source block again and it will work
(see attached fc2580-2.txt). So it seems there is something wrong with
the
tuner initialization. I didn’t have time to look into what the problem
could be.

Alex

Balint

Thanks this is really incredible.

I just got a Noxon DAB Stick (Ver 1) and it works flawlessly. In some
ways it’s better for my application because their are few spurious
signals.

The driver is almost a drop in replacement for the UHD.

What a bonus all of this is to the SDR community.

Have you considered adding the capability of using more than one device
at a time.

David

Thanks for testing Alex!

I know it works for you now, but just in case others have experienced
the
same problem, please update your code.

The latest has support for the four major tuners (with auto-probing),
and
some more devices too.

Balint

From: discuss-gnuradio-bounces+balint256=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+balint256=removed_email_address@domain.invalid] On Behalf
Of
Alexandru C.
Sent: Friday, 6 April 2012 10:03 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] Update: RTL2832 re-written (better GRC
block, librtl2832++) & works with OP25 digital radio!

Balint,

Thanks for your work on this. Yesterday I have been playing with my EzTV
666
and today I tried a Dexatek dongle using your latest code with FC2580
tuner
support.

If I try to run a simple src->fft flowgraph (attached) right after
plugging
the dongle in I get a bunch of errors, see atached fc2580-1.txt file. I
tried to capture a file using the latest rtl-sdr code from the osmocom
repository using the same frequency and sample and it worked. After that
I
can try the grc flowgraph using your source block again and it will work
(see attached fc2580-2.txt). So it seems there is something wrong with
the
tuner initialization. I didn’t have time to look into what the problem
could
be.

Alex

On Thu, Apr 5, 2012 at 1:55 PM, Balint S. [email protected]
wrote:

Hi folks,

Firstly, thank you to those who have tested the initial release and have
been in touch with feedback - I really appreciate it.

I would like to share the completely re-written RTL2832 code in gr-baz
http://wiki.spench.net/wiki/gr-baz#rtl_source_c , which should now
support
all devices I can find with an E4000, FC0013 and now FC0012 tuner (if
there
are any missing, you can simply set the custom VID/PID in the GRC
RTL2832
Source block, or add just one line to an array in rtl2832.cc). This will
be
ported to the Windows plugin soon.

The RTL2832 Source block code itself is much tidier, and makes use of
(what
I submit for your consideration/experimentation as) ‘librtl2832++’ -
this is
a completely re-designed GNU Radio-independent C++ (OO) interface to the
hardware. The idea is to make it really easy to talk to the dongles. If
you
want to use it for something else, just copy out the ‘rtl2832-*’ files!
You
will find the main ‘demod’ class, and the 'tuner’s, all with (I hope) a
simple API.

The updated GRC Source block also exposes lots of new settings too
(including bandwidth, buffer settings, FIR coefficients, .).

Moreover, just to ensure that I hadn’t led people down the garden path
(since, let’s face it, it’s 8 bits, XO drifts like crazy, and wasn’t
designed for general-purpose SDR), I hooked it up to OP25
http://op25.osmocom.org/ (the open source P25 digital radio decoder)

and happily it works!

Check out the RTL2832+OP25+DES-OFB demonstration/RTL2832 update video:

In the process I also created two new GRC blocks (now in gr-baz, also in
the
video):

  1.   'OP25 Decoder' (float baseband in, audio out with optional
    

parameter for setting DES-OFB decryption key - this requires a patch
with
decryption support that I will release soon)

  1.   'Message Callback' sink whose input port accepts messages, and
    

calls the relevant GRC-generated code to update a GRC variable (i.e. you
can
have various blocks that output messages into a message queue, and these
will be picked up by this block and trigger a particular variable in
your
flowgraph to by updated automatically - e.g. you can change a tuning
offset
if a block detects a frequency error creeping in, and/or you can have
GUI
elements - text boxes/sliders/etc - controlled by arbitrary blocks if
their
value needs to be updated by a feedback mechanism)

Please note: RTL2832’s Source block now has Relative Gain enabled by
default, so valid gain values are in the range [0,1]. This means you
don’t
need to remember the absolute gain range for whichever tuner you have!

Also, there is a known issue that may occur while tuning. If you change
the
frequency too rapidly, a USB error may occur and require reconnection of
the
dongle (this has only ever happened to me though when there are sample
rate
mismatches in a flowgraph). Enforcing coarse-grained locking in the
source
block code does not solve this. The only obvious fix to me at this stage
is
rate-limiting tuning requests (I’m guessing perhaps the device wasn’t
designed to expect rapid re-tuning). Implementing async libusb control
transfers would also be nice!

Finally, I have found that on my Linux box, streaming performance isn’t
as
great as on Windows. By ‘performance’ I mean occasional degradation in
the
baseband signal (i.e. signal ‘jumps’, after AM or FM demod of a constant
tone, you would hear a ‘click’ discontinuity). I hope that’s not a
result of
an undiscovered bug, but I’ve been largely able to avoid these
discontinuities by selecting a modest sample rate (e.g. 1 Msps),
increasing
the transfer read length (you can do this easily in the GRC block) to
e.g.
256K (though this will increase delay in reflection of freq/gain changes
in
output signal due to longer buffer), and enabling real-time scheduling
(this
requires root).

If you get run-time complaints about it not finding certain libraries,
don’t
forget to run ‘sudo ldconfig’.

If you do try it out, please let me know how you go! I only have one
adapter
with the E4000, so I haven’t actually tested any others myself. Fingers
crossed!

Kind regards,

Balint @spenchdotnet http://twitter.com/spenchdotnet