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

[Balint Seeber]

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, 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 (the open source P25 digital radio decoder) – and happily it works!

 

Check out the RTL2832+OP25+DES-OFB demonstration/RTL2832 update video: http://www.youtube.com/watch?v=wShOLgW2tmI

 

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)

2.       ‘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