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
all devices I can find with an E4000, FC0013 and now FC0012 tuner (if
are any missing, you can simply set the custom VID/PID in the GRC
Source block, or add just one line to an array in rtl2832.cc). This will
ported to the Windows plugin soon.
The RTL2832 Source block code itself is much tidier, and makes use of
I submit for your consideration/experimentation as) ‘librtl2832++’ -
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
want to use it for something else, just copy out the ‘rtl2832-*’ files!
will find the main ‘demod’ class, and the 'tuner’s, all with (I hope) a
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
'OP25 Decoder' (float baseband in, audio out with optional
parameter for setting DES-OFB decryption key - this requires a patch
decryption support that I will release soon)
'Message Callback' sink whose input port accepts messages, and
calls the relevant GRC-generated code to update a GRC variable (i.e. you
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
flowgraph to by updated automatically - e.g. you can change a tuning
if a block detects a frequency error creeping in, and/or you can have
elements - text boxes/sliders/etc - controlled by arbitrary blocks if
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
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
frequency too rapidly, a USB error may occur and require reconnection of
dongle (this has only ever happened to me though when there are sample
mismatches in a flowgraph). Enforcing coarse-grained locking in the
block code does not solve this. The only obvious fix to me at this stage
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
great as on Windows. By ‘performance’ I mean occasional degradation in
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
an undiscovered bug, but I’ve been largely able to avoid these
discontinuities by selecting a modest sample rate (e.g. 1 Msps),
the transfer read length (you can do this easily in the GRC block) to
256K (though this will increase delay in reflection of freq/gain changes
output signal due to longer buffer), and enabling real-time scheduling
If you get run-time complaints about it not finding certain libraries,
forget to run ‘sudo ldconfig’.
If you do try it out, please let me know how you go! I only have one
with the E4000, so I haven’t actually tested any others myself. Fingers
Balint @spenchdotnet http://twitter.com/spenchdotnet