In Testing: Customized Drivers for RTL-SDR Blog V3 SDRs

We've recently released a modified version of the Osmocom RTL-SDR drivers that has a few enhancements particularly for RTL-SDR Blog V3 units. The changes merge improvements to L-Band PLL locking performance which may be necessary for operating units in high ambient heat environments and the RTL_TCP performance enhancements by Stephen Blinick.

If you want to toggle the bias tee ON/OFF in SDR#, we've also made use of the "Offset Tuning" checkbox in the RTL-SDR settings. This checkbox is unused for R820T2 RTL-SDRs, so we've added code that will toggle the bias tee ON/OFF with this checkbox. 

In addition we've also made use of some unused EEPROM flags to create a method that allows you to force the bias tee to be always ON if a certain EEPROM flag is set. You can also force direct sampling mode with another EEPROM flag. Note that these force flags will only work if you are using these drivers.

A Windows release is available on the Github Releases. To use with SDR#, simply replace the rtlsdr.dll file in the SDR# folder with the one in the file. To install on Linux, follow the instructions in the Readme, and remember to follow the instructions to remove librtlsdr-dev if you previously installed drivers via the package manager.

If there are any problems or feedback, please open an issue on GitHub. List of changes shown below.

1) VCO PLL current fix - Improves stability at frequencies above ~1.5 GHz

2) RTL_TCP ring buffer enhancement by Stephen Blinick

3) Enabled direct sampling for rtl_tcp

4) rtl_biast program added, including the ability to turn on/off any GPIO

5) Hack to force the bias tee to always be on by setting the unused IR endpoint bit to 0 in the EEPROM. Example to force the BT to be always ON "rtl_eeprom -b y", to remove forced BT "rtl_eeprom -b n"

6) Hack to force direct sampling to be always on by setting the unused remote-enabled bit to 1 in the EEPROM. Example to force direct samping always "rtl_eeprom -q y". To remove forced direct sampling "rtl_eeprom -q n"

7) Repurposed "offset tuning" to toggle bias tee ON/OFF. We can now use the "offset tuning" button in SDR# and other programs to toggle the bias tee if there is no specific button in the GUI.
Notify of

Inline Feedbacks
View all comments

Good news, discussion has resumed on the ring buffer pull request and Steve from oscom has chimed in:

Based on the date it is almost certainly due to your blogpost. Still doesn’t mean it will be merged mainline, but at least it is being considered now, possibly as a command line switch that offers it as an alternative.


I have been using this driver fork for 4 months or so with great results.
I use the v3 with a raspberry pi zero w, rtl_tcp with direct sampling i can sustain 1.8Ms before i begin to experience sample loss. not sure whats under the hood, but i suspect the network or my old laptop is to blame not the drivers. i use “rtl_tcp -a x.x.x.x -D 2” on the pi side and “rtl_tcp=x.x.x.x:1234,direct_samp=2” on gqrx. works great, not without hiccups. We know the osmocom drivers are pure shit for this configuration. I tried out your new driver and found it to be very similar in performance to the one linked to above, didn’t get the sample rate above 1.2Ms, but once again i have a spartan set up and hiccups happen.
Thanks Mr. Carl, look forward trying out the other improvements.
P.S. i recall an issue with rtl_fm, that you had to change the c file to point the direct sampling to the q branch prior to compilation. is this still a thing? maybe i will play around and answer my own question. Thanks again Carl for all this work.


Seems okay here, love the bias-t toggle in offset tuning settings. Thanks.

Rodrigo F

Great to see you shipping the rtl_tcp patchset, Carl!

Unfortunately, seems that the upstream purists are more focused in the Perfection (and all the hurdles) versus the Good Enough.

Great job, Carl!

73 de PY2RAF.


Thanks for the new drivers.
I hope that beginners won’t turn on the bias tee by mistake.
Will the bias tee option work via the spyserver?




Those are interesting and useful improvements and I’m happy to see that the project is alive and evolving.
Regarding bias tee and offset tuning – does it work like “if offset tuning is enabled and the offset is 0 then enable bias tee”?


Thanks for the clarification, now it’s 100% clear!