How to power OFF the BIAS of RTL-SDR V4 in ultrafeeder?

Hi,
got my original RTL-SDR.COM V4 today and found the 5V BIAS is always present.
I tried

READSB_ENABLE_BIASTEE=false

in docker-compose.yml, restarted docker, even restarted whole Pi3. But this did nothing, still power on the line.
How can I switch it off?

(Want to test a CoCo, which has short circuit at the whip, this would kill the V4 I guess)

docker logs ultrafeeder 2>&1 | grep bias

can you show that output?

Aaaah, I see … the documentation in github told “true / false”, the log entry points to expected “ON/OFF”.
I’ll retry with OFF. If this is the right combination, please let me create a fix and a git pull request for the documentation.

It shouldn’t matter, that’s why i asked for the log.

You’re just assuming yes? Because i’ve looked at the script in question.

Can you show that log? It shouldn’t show anything private when grepping for bias.

Guess i should just link:
https://raw.githubusercontent.com/sdr-enthusiasts/sdre-bias-t-common/main/09-rtlsdr-biastee-init
https://github.com/sdr-enthusiasts/docker-baseimage/blob/main/scripts/common#L20

Hmm … nearby, bit still missed a bit:

docker-compose.yml,

environment:
  ...
  - READSB_ENABLE_BIASTEE=OFF

resulting in

$ docker logs ultrafeeder 2>&1 | grep bias
s6-rc: info: service 09-rtlsdr-biastee: starting
[2025-01-31 16:56:39.022][09-rtlsdr-biastee-init] Device type is rtlsdr, checking for bias tee...
[2025-01-31 16:56:39.167][09-rtlsdr-biastee-init] Disabling bias tee...
[2025-01-31 16:56:39.187][09-rtlsdr-biastee-init] Found 1 device(s):
[2025-01-31 16:56:39.207][09-rtlsdr-biastee-init]   0:  RTLSDRBlog, Blog V4, SN: 00000001
[2025-01-31 16:56:39.207][09-rtlsdr-biastee-init]
[2025-01-31 16:56:39.219][09-rtlsdr-biastee-init] Using device 0: Generic RTL2832U OEM
[2025-01-31 16:56:39.294][09-rtlsdr-biastee-init] Detached kernel driver
[2025-01-31 16:56:39.559][09-rtlsdr-biastee-init] Found Rafael Micro R828D tuner
[2025-01-31 16:56:39.559][09-rtlsdr-biastee-init] RTL-SDR Blog V4 Detected
[2025-01-31 16:56:40.089][09-rtlsdr-biastee-init] Reattached kernel driver
s6-rc: info: service 09-rtlsdr-biastee successfully started

docker-compose.yml,

environment:
  ...
  - READSB_ENABLE_BIASTEE=ON

resulting in

 $ docker logs ultrafeeder 2>&1 | grep bias
s6-rc: info: service 09-rtlsdr-biastee: starting
[2025-01-31 16:58:14.070][09-rtlsdr-biastee-init] Device type is rtlsdr, checking for bias tee...
[2025-01-31 16:58:14.197][09-rtlsdr-biastee-init] Enabling bias tee...
[2025-01-31 16:58:14.216][09-rtlsdr-biastee-init] Found 1 device(s):
[2025-01-31 16:58:14.238][09-rtlsdr-biastee-init]   0:  RTLSDRBlog, Blog V4, SN: 00000001
[2025-01-31 16:58:14.238][09-rtlsdr-biastee-init]
[2025-01-31 16:58:14.250][09-rtlsdr-biastee-init] Using device 0: Generic RTL2832U OEM
[2025-01-31 16:58:14.322][09-rtlsdr-biastee-init] Detached kernel driver
[2025-01-31 16:58:14.600][09-rtlsdr-biastee-init] Found Rafael Micro R828D tuner
[2025-01-31 16:58:14.600][09-rtlsdr-biastee-init] RTL-SDR Blog V4 Detected
[2025-01-31 16:58:15.061][09-rtlsdr-biastee-init] Reattached kernel driver
s6-rc: info: service 09-rtlsdr-biastee successfully started

Both seem to enable the BIAS. Why do I believe it? Well, I am using an active antenna, and with both settings I get many planes flying around in web view at distances of more than 70 km. could climb to the shed’s roof and measure the line, but I am quite sure, the https://de.aliexpress.com/item/1005007735199789.html antenna would not beyond 10 nm without power supply.
Shall I grab my meter and climb?

                            "${s6wrap[@]}" echo "Disabling bias tee for device $device_id:  $device_manufacturer, $device_model, SN: $device_serial"
                            "${s6wrap[@]}" rtl_biast -d "$device_id" -b 0


                "${s6wrap[@]}" echo "Disabling bias tee..."
                "${s6wrap[@]}" rtl_biast -b 0

Those are the lines that have “Disabling” in them.
As you can see it calls rtl_biast -b 0 in both cases.

It’s all osmocom software so it should work fine for v4.
I believe you that it’s not switching it off, but it could just be an issue with the SDR.

Would be a little more clear if it would just output the command it’s gonna use but i don’t see any functional issues with the container.

Thank you once more for the investigation.

Regarding the planned CoCo test … some days before I ordered another stick for a friend, this time “The Blue one” (https://de.aliexpress.com/item/1005005466363998.html). Specs are telling nothing about BIAS for the blue stick. So I can delay my CoCo-Antenna experiments until then.

Anyway, I’d love to learn if my V4 is defective. If anyone else could verify, if the recent container does switch off BIAS with their V4 sticks, it could help a lot to argument with the supplier.

So, please all other readers and RTL-SDR V4 owners, could you please confirm that this setting in ultrafeeder’s /opt/apt/docker-compose.yml

...
  environment:
    ...
    - READSB_ENABLE_BIASTEE=OFF

does switch off the BIAS with yours?

I mean just try rtl_biast without the container?
Just gotta get the v4 drivers first.

I am not very familiar with the architecture, just an old man who can C++ and playing with docker containers made by smarter people :wink:
Could you please point me to a web site where I can get the missing knowlege?

BTW, another question about BIAS and my passive home brew antennas:
Could I use this one as a BIAS voltage stopper? I’d guess the brown thing in the HF path is a capacitor(?) My idea is to insert this one into my antenna cable and to omit the USB supply. That should let pass the HF and stop the bias, right?

Yep that’s indeed how it works.

You can just try installing rtl-sdr with apt and using rtl_biast while the container is stopped.
Make the biastee setting for the container an empty string and start the container.
With the string empty it will leave the biastee in the state it is in.

Thanks, right.
I started with GitHub - rtlsdrblog/rtl_biast: Bias tee software for the RTL-SDR.com V3 Dongle, and found it quite badly documented and outdated, other google proposals are only talking about V3

Now I found RTL-SDR Blog V4 Users Guide. Together with your hint, it is enough documentation :slight_smile:. Will get the hardware tomorrow from the shed’s attic and try it soon.

If you insert that Bias-T into your feed and point the “RF&DC” port to the receiver, the Bias-T LED will tell you if the V4 is feeding power (while blocking the DC to the antenna).

Hi @wiedehopf ,

the Blog V4 stick is switching the bias as required. So I am afraid the “locked” bias is caused by some piece of software or configuration mistake somewhere.

To verify the Blog V4 stick, I did:

  • set up an fresh, clean Pi4 (the problem arised with Pi3, docker, ultrafeeder)
  • followed the RTL-SDR Blog V4 Users Guide instructions,
  • connected the V4,
  • reboot,

then I did:

me@pi4:~ $ rtl_biast -d 0 -b 1
Found 1 device(s):
  0:  RTLSDRBlog, Blog V4, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R828D tuner
RTL-SDR Blog V4 Detected
me@pi4:~ $ # -- some milliseconds after issuing above command, the bias gets ON, okay
me@pi4:~ $
me@pi4:~ $ rtl_biast -d 0 -b 0
Found 1 device(s):
  0:  RTLSDRBlog, Blog V4, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R828D tuner
RTL-SDR Blog V4 Detected
me@pi4:~ $ # -- some milliseconds after issuing above command, the bias gets OFF, okay

What’s my most likely fault with the Pi3/docker/ultrafeeder setup?
What to investigate next?

FOUND IT!

My fault :face_with_peeking_eye:.
Some weeks before, I replaced the Pi3 by another one. According to the shell history, I did everything I did on the 1st computer, except create the blacklist.

Back on the Pi3 I caught up on it today.

For later readers, do not forget or mistype the blacklist, otherwise your docker host seemingly forces the bias to be ON:

echo 'blacklist dvb_usb_rtl28xxu' | sudo tee --append /etc/modprobe.d/blacklist-dvb_usb_rtl28xxu.conf

Is’t all well now!!
THX

Tank you, nice hint. Helped me a lot!

Oh the kernel is turning the biastee on instantly after the container turns it off during startup.

The kernel defaulting to biastee on is … not good.
At least that’s what i presume is happening.