Appendix 2 - Using RTL-SDR GPIO

Foreword - Some GPIO quirks

• After some investigation, I've found that the Header 30 (GPIO 4) is turned ON by default (in biased state, +3.3V), as soon you plug in the USB dongle. It is by hardware design, not related to software or drivers. While you can flip its state normally using the tools, keep in mind that this line specifically is on by default. This can be desirable in some designs.

• Headers 29, 31 and 32 (GPIOs 5, 2 and 1, respectively) might provide a vestigial 100 mV tension in its initial state (i.e. upon plug in and power-up) - click the link for the video - and this can be enough to signal "on" in some implementations. In order to drop the line to 0V, either use a pull-down resistor or just bias the GPIO line to 0 - By biasing the GPIO line to 0 drops the voltage to 0V.

• The ON/UP state in the GPIO lines signals +3.3V.

• Conversely, the OFF/DOWN state presents 0V.

• The RTL2832U GPIO lines are not protected against static discharge - If your project (or handling) involves external interfacing, ensure to provide proper ESD protection.

Changing GPIO states

In order to be able to use the RTL-SDR's GPIO ports, you will need the rtl_biast tool from this special RTL-SDR Blog build.

While in RTL-SDR you have the markings 29, 30, 31 and 32, these does not correspond to the actual GPIO number.

RTL-SDR GPIO header

Use the following table to translate the board numbers to the actual GPIO number:

SDR PIN	GPIO NR
29	5
30	4
31	2
32	1

RTL-SDR board GPIO and Software GPIO mapping

After installing the required (if your Windows doesn't have it) Windows C++ runtimes, use the rtl_biast.exe file to flip the GPIO signal of interest.

For example, flipping the GPIO Pin 31 to ON:

> rtl_biast -d 0 -b 1 -g 2

The above command translates to:

• -d 0 - RTL-SDR Board #0 (use the proper number if you have more than one dongles)
• -b 1 - Enable signal. Conversely, to turn the signal off use -b 0
• -g 2 - GPIO #2, translated from SDR Header 31 from aforementioned table

Currently, there are no software provisions to find out the current bias state of each GPIO port. There's a pull request for showing the Bias Tee current state - But nothing involving the individual GPIO ports.