Not receiving messages with Readsb vs Dump1090-fa

[Guzbikes]

I have my "full stack" setup running on a Raspberry Pi4 using Docker compose, and I am receiving messages when I use a Dump1090 container. However, when stop the Dump1090 container and switch to this Readsb container, I am getting 0 messages, even though it seems to be seeing the RTL SDR just fine.

Here is the startup log of the container:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.

[s6-init] ensuring user provided files have correct perms...exited 0.

[fix-attrs.d] applying ownership & permissions fixes...

[fix-attrs.d] done.

[cont-init.d] executing container initialization scripts...

[cont-init.d] done.

[services.d] starting services

[services.d] done.

Sat Apr 25 19:49:59 2020 UTC  Mictronics v3.8.2 starting up.

rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)

Found Rafael Micro R820T tuner

rtlsdr: tuner gain set to 49.6 dB

Allocating 16 zero-copy buffers

Is it possible I need different settings for my RTL SDR? I have the NooElec Nesdr Mini 2+

Here is the relevant section of docker-compose.yml:

  readsb:
    image: mikenye/readsb:latest
    tty: true
    container_name: readsb
    restart: always
    devices:
      - /dev/bus/usb/001/003:/dev/bus/usb/001/003
    ports:
      - 8080:80
      - 30005:30005
      - 30003:30003
    networks:
      - adsbnet
    volumes:
      - readsbjsondata:/var/run/readsb
    command:
      - --dcfilter
      - --device-type=rtlsdr
      - --fix
      - --forward-mlat
      - --json-location-accuracy=2
      - --lat=33.00000
      - --lon=-111.00000
      - --mlat
      - --modeac
      - --ppm=0
      - --net
      - --stats-every=3600
      - --quiet
      - --write-json=/var/run/readsb

[Guzbikes]

Here is the container log when I start dump1090, it looks like the only real difference is the last line about the zero-copy buffers:

Sat Apr 25 20:03:07 2020 UTC  dump1090-fa  starting up.

rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)

Found Rafael Micro R820T tuner

rtlsdr: tuner gain set to 49.6 dB

Allocating 4 zero-copy buffers

Detected Kernel usbfs mmap() bug, falling back to buffers in userspace

[Guzbikes]

I just noticed you already figured this out on your Piaware docker build: https://github.com/mikenye/docker-piaware/issues/15

And it looks like this may have something to do with the RTL-SDR image and the USB DOngle hardware that I'm using: RTL2838UHIDIR

I cloned your readsb repo and made the same change to the RTL-SDR version in the Dockerfile that was the fix in Piaware: https://github.com/mikenye/docker-piaware/issues/15#issuecomment-614855190

But I am now getting this error trying to run with the older version of RTL SDR:

sdr_rtlsdr.c: In function 'rtlsdrOpen':
sdr_rtlsdr.c:230:5: error: implicit declaration of function 'rtlsdr_set_bias_tee'; did you mean 'rtlsdr_set_xtal_freq'? [-Werror=implicit-function-declaration]
     rtlsdr_set_bias_tee(RTLSDR.dev, Modes.biastee);
     ^~~~~~~~~~~~~~~~~~~
     rtlsdr_set_xtal_freq
cc1: all warnings being treated as errors
make: *** [Makefile:60: sdr_rtlsdr.o] Error 1

[Guzbikes]

Since the error above looked like an issue with bias tee support, which my dongle does not have, I changed another line the the Building readsb section:

make RTLSDR=yes BLADERF=no PLUTOSDR=no HAVE_BIASTEE=no && \

I think changing HAVE_BIASTEE=yes to HAVE_BIASTEE=no is the only needed change there, but since I only want RTLSDR, I changed those other make commands to "no" too, just to save time.

After this change, and the earlier change to the Dockerfile:

git checkout tags/v0.5.3 && \
    echo "rtl-sdr v0.5.3" >> /VERSIONS && \

I was able to build the readsb image. And now I am seeing aircraft using readsb with the RTL2838UHIDIR dongle.

[mikenye]

Hi @Guzbikes, thanks so much for doing some troubleshooting and getting v0.5.3 compiling without HAVE_BIASTEE.

I've had a look through the commit log to the rtlsdr project, the only commit since v0.5.3 that mentions biast is this one: http://git.osmocom.org/rtl-sdr/commit/?id=43b257854c2c4f6d30649e34d1d1473e72630c5a

I've created a branch "issue_3" where I've changed the version of rtlsdr to the most recent commit.

Unfortunately the SD card in my Odroid HC1 (my armv7l build platform) died overnight so I'll need to get a replacement before I can build for this platform.

I've attempted a build on amd64, which builds and runs OK for me (but I'm not using RTL2838UHIDIR)...

Out of interest, what architecture are you operating this on? Did you want to try building from branch "issue_3"?

[Guzbikes]

Do you want me to try building the RTLSDR 0.6.0 and try it with biastee=no? It originally built fine wth biastee=yes, but no planes were seen on the RTL2838UHIDIR dongle hardware, as you found out in your Piaware Docker image.

[mikenye]

Please feel free to try, howeever I don't necessarily want to update the image to remove biastee support in case others are using it. I suppose I could make a -nobiastee tag...

[Guzbikes]

I was thinking that you may need to have a 0.5.3 branch, like you have for the piaware image, for the RTL2838UHIDIR hardware. ANd I think that one would have to have the biastee option removed since it is apparently not supported with that version,

[mikenye]

Agreed. I was hoping there may be a more recent version (commits beyond 0.6.0) of rtlsdr that are stable and support biastee as well as RTL2838UHIDIR... The version in branch issue_3 is the latest commit.

[Guzbikes]

Ah gotcha, ok I'll give it a try with the latest and see what happens. That's the nice thing about Docker, just start/stop, easy! :-)

[mikenye]

Yep! Love docker for this. Thanks so much. New SD card is here so my build cluster should be back online in a few hours...

[Guzbikes]

Ok, I pulled and checked out the issue-3 branch and built it under a new image name. I just started it and I am seeing aircraft! Though it is 2am here and there is only one police helicopter atm... I'm on the Discord now too so I'll let it run for a while, and I'll let you know how it goes.

[mikenye]

Hi @Guzbikes, this should be resolved in latest now. Could you please test and confirm? Thanks.

[mikenye]

@Guzbikes reports issue solved via ADSBx discord :)