@Thom-x any plans om this? Are you still maintaining this repo?

Sorry I don't have the hardware to test and implement this. Nevertheless, pull requests are welcome. 🙂

Hopefully someone can assist you with implementation. I have the hardware, not the skills. ;)

Hello! I've enabled Bias Tee for RTL SDR v3 by making modifications to the container's code. Sorry, couldn't do it as pull request since I've forked the repo once and couldn't do any more forks.

I've attached diff and the resulting files.

Change log:

• Rebased to RTL SDR Blog driver v1.3.6 as that's the only way to enable BiasTee control
• Updated dump1090 run script to enable BiasTee at start.

TODO:

• Add enable/disable configuration option for biast on container level

You can preview the enhancement in this container: https://hub.docker.com/repository/docker/rpavlyuk/fr24feed-piaware

bias-tee-feature.diff.txt
Dockerfile.txt
s6-rc.d_dump1090_run.txt

That's cool @rpavlyuk, a 1st step to get this option into the add-on for HA!
Thank you!

Unfortunately, I have no enough time to take a look into HA add-on :( But I promise to get to it as soon as I can.

@rpavlyuk @ExquisiteMetropolis If you still want to try it, the feature is available in #185 under tag PR-185, you need to have env var SERVICE_ENABLE_BIAST=true .

Cool! Thanks, I will, and let you know the outcome. Might take a few days / up to a week.

I've been attempting to get it to work, I run into a challenge.

I happen to have 2 installed, on for 1090Mhz and the other for 433Mhz.
In order to avoid conflict, I need to be able to provide an option on which dongle to use.
Does your docker container allow for the selection of a specific RTLSDR dongle based on it's internal serial number?

My current feeder (ultrafeed) has an option for that: RTLSDR_DEVICE=<s/n> (and so does the container for the 433Mhz one).
I didn't find something like this in your documentation, did I overlook this? Or will the be a new feature request?

For testing I will disconnect the 433Mhz one temporally. However, that will take some effort as it's of course neatly organized away. ;)

You should be able to pass the device you want to the docker container,

Instead of

    devices:
      - "/dev/bus/usb"

Do

    devices:
      - "/dev/bus/usb/mydevice"

Thanks for the prompt reply.
I determined the following (just for reference for others, as BIAS-T should not be turned on for dongles that have no need for it, should also be turned off by default in the final config).

lsusb -tvv

Which returned:

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    /sys/bus/usb/devices/usb1  /dev/bus/usb/001/001
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        ID 2109:3431 VIA Labs, Inc. Hub
        /sys/bus/usb/devices/1-1  /dev/bus/usb/001/002
        |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            ID 05e3:0610 Genesys Logic, Inc. Hub
            /sys/bus/usb/devices/1-1.2  /dev/bus/usb/001/003
            |__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
                ID 05e3:0610 Genesys Logic, Inc. Hub
                /sys/bus/usb/devices/1-1.2.1  /dev/bus/usb/001/005
                |__ Port 3: Dev 7, If 1, Class=Vendor Specific Class, Driver=, 480M
                    ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
                    /sys/bus/usb/devices/1-1.2.1.3  **/dev/bus/usb/001/007**
                |__ Port 3: Dev 7, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
                    ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
                    /sys/bus/usb/devices/1-1.2.1.3  /dev/bus/usb/001/007
        |__ Port 4: Dev 4, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
            ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
            /sys/bus/usb/devices/1-1.4  **/dev/bus/usb/001/004**
        |__ Port 4: Dev 4, If 1, Class=Vendor Specific Class, Driver=, 480M
            ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
            /sys/bus/usb/devices/1-1.4  /dev/bus/usb/001/004

The s/n of the dongles could be found via:

usb-devices

T:  Bus=01 Lev=02 Prnt=06 Port=03 Cnt=01 **Dev#=  4** Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=2838 Rev=01.00
S:  Manufacturer=Realtek
S:  Product=RTL2838UHIDIR
**S:  SerialNumber=00000001**
C:  #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbfs
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)


T:  Bus=01 Lev=04 Prnt=05 Port=02 Cnt=01 **Dev#=  7** Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=2838 Rev=01.00
S:  Manufacturer=Realtek
S:  Product=RTL2838UHIDIR
**S:  SerialNumber=00000002**
C:  #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbfs
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

Matching the usb-devices output "Dev#= 4" with lsusb-tvv output: "/dev/bus/usb/001/004" and the s/n I determined that this is the matching dongle in this case.

I do hope the mapping of the /dev/bus/usb/001/004 remains fixed upon reboots (and possible reconnects of devices during maintanance for what ever reason).
When using the actual s/n I'm always certain that I have the correct dongle.

Next step in the coming days is to turn off the current container(s), start up this one and do a power cycle.
(where BIAS-T will be disabled at first, where I will cycle the container with BIAS-T enabled to see the effect).
Stay tuned. ;)

Decided to continue testing.

Created the container with the following parameters:

docker create \
 -it \
 --restart=always \
 --name fr24feed-piaware \
 --hostname fr24feed-piaware \
 --device=/dev/bus/usb/001/004 \
 --tmpfs=/run:exec,size=256M \
 --tmpfs=/planefinder/log:exec,size=32M \
 --tmpfs=/usr/lib/fr24/public_html/data:size=32M \
 --restart unless-stopped \
 -v /etc/localtime:/etc/localtime:ro \
 -p 8754:8754 \
 -p 8787:8080 \
 -p 30005:30005 \
 -p 30053:30053 \
 -e FR24FEED_FR24KEY=<KEY> \
 -e PIAWARE_FEEDER_DASH_ID=<ID> \
 -e HTML_SITE_LAT=<LAT> \
 -e HTML_SITE_LON=<LON> \
 -e HTML_SITE_ALT=6 \
 -e HTML_SITE_NAME=<NAME> \
 -e PANORAMA_ID=<ID> \
 -e SERVICE_ENABLE_ADSBEXCHANGE=true \
 -e ADSBEXCHANGE_UUID=<ID> \
 -e ADSBEXCHANGE_STATION_NAME=<NAME> \
 -e MLAT_EXACT_LAT=<LAT> \
 -e MLAT_EXACT_LON=<LON> \
 -e MLAT_ALTITUDE_MSL_METERS=6 \
 -e SERVICE_ENABLE_PLANEFINDER=true \
 -e PLANEFINDER_SHARECODE=<CODE> \
 -e SERVICE_ENABLE_OPENSKY=false \
 -e SERVICE_ENABLE_ADSBFI=false \
 -e SERVICE_ENABLE_RADARBOX=true \
 -e RADARBOX_SHARING_KEY=<KEY> \
 -e SERVICE_ENABLE_ADSBHUB=false \
 -e SERVICE_ENABLE_BIAST=true \
 thomx/fr24feed-piaware:PR-185

Starts just fine. In the logs I can see:

s6-rc: info: service biast: starting
[biast] Enabling bias-tee for RTL-SDR V3...
[biast] Found 2 device(s):
HTTP request sent, awaiting response... [biast]   0:  Realtek, RTL2838UHIDIR, SN: 00000001
[biast]   1:  Realtek, RTL2838UHIDIR, SN: 00000001
[biast] 
[biast] Using device 0: Generic RTL2832U OEM
[biast] Found Rafael Micro R820T tuner
[biast] SUCCESS: Bias Tee enabled
200 OK

So that looks good. Ran the container for a few mintues to see what is picked up.
Unfortunately, significantly less traffic than expected. I'm not yet sure to why/what the reason is.
I tried to run the container with & without BIAS-T, both produce the same result.
The filter is powered on (so the BIAS-T setting did work). So the cause must be found somewhere else.

Also tested without a power cycle, when starting 'ultrafeed' the range is to what I normally expect.
Stopping that container and spooling up yours (without reboot), results in less range.
Could it be related to this setting missing? https://github.com/sdr-enthusiasts/docker-readsb-protobuf/#estimating-ppm
Or should I dig somewhere in logs & settings else to help determine the cause?

Images, with less range is the PR-185 container running.

This is what I do to tweak ppm, not sure if it is the cause of the bad range though.
- "DUMP1090_ADDITIONAL_ARGS=--json-location-accuracy 2 --gain 49.6 --ppm 60 --net-bi-port 30004,30104"

Thanks, added this to the config but no change unfortunately.

What I will try (later) is to physically disconnect the other dongle.
Although the logs indicate the correct one being used, I suspect it might not be.
The logs also show "Found 2 device(s)", which concerns me a bit.
Simple test, to rule it out at least.

By the way, Radarbox has renamed itself to AirNavRadar ;-)

You can also override the default biast arguments, maybe it's picking the first one and it should be the other?

I've tested some more. Physically removed the other RTL dongel I use.
Still the same results, far less reception. Same system/hardware, different container.
What do you need form me to help trouble shoot this issue further?