Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG: Enable gain controls and consistent options across RTL-SDR devices #1467

Closed
gvimlag opened this issue Oct 5, 2022 · 4 comments · Fixed by #1495
Closed

BUG: Enable gain controls and consistent options across RTL-SDR devices #1467

gvimlag opened this issue Oct 5, 2022 · 4 comments · Fixed by #1495
Assignees

Comments

@gvimlag
Copy link

gvimlag commented Oct 5, 2022

Please add to the RemoteTCPInput device (when using remote rtl_tcp server):

  Enable gain controls ability to alter the signal gain
  DC - Software DC block
  IQ - Software IQ correction

Please add to the SoapySDR[1:0] device (when using remote SoapySDR server with an RTL-SDR):

  Bias T

Images showing the issues:
The following images all use the same RTL-SDR dongle.

The first row of 3 images shows 3 different gain settings and spectrums for the RemoteTCPInput device using remote rtl_tcp server.
These images show that the gain and AGC controls do NOT alter the signal level (remains at about -75dB, unchanged for all 3 gain settings).

rtl_tcp

In contrast, the second and third rows of images show gain settings and spectrums for the RTL-SDR[0] device with local connection, and the SoapySDR[1:0] device with remote SoapySDR server, respectively.
These images show that for these other two devices, the gain and AGC controls DO alter the signal level (about -75dB to -50dB, and about -85dB to -60dB respectively).
So it appears something is wrong with the gain controls on the RemoteTCPInput device since its gain controls don't effect its signal level.

local

soapy

These images also show that the DC and IQ options are missing from the RemoteTCPInput device,
and that the "Bias T" option is missing from the SoapySDR[1:0] device.


Problems caused by gain control and DC/IQ issues:
FM broadcast audio is lost or sporadic when using rtl_tcp server on a "Raspberry Pi 4B" feeding RemoteTCPInput.
(Other server/device combinations do NOT have this issue. This audio issue only happens with rtl_tcp and RemoteTCPInput.)

To determine the cause of this issue, I first verified that the rtl_tcp server worked by testing it with other SDR packages.
I fed rtl_tcp into both SDR++ and Gqrx. Both SDR packages play FM audio with no problem. So rtl_tcp is working.

Then I tested the SDRangel "Broadcast FM Demodulator".
I fed rtl_tcp/RemoteTCPInput into "Broadcast FM demodulator" and found that the FM audio was lost or sporadic on the same stations that worked for SDR++ and Gqrx.
Next, I fed direct-connected/RTL-SDR[0] and SoapySDR/SoapSDR[1:0] into "Broadcast FM demodulator" and found that the FM audio worked for both devices.
So the SDRangel "Broadcast FM Demodulator" was not the problem, because it worked with direct-connected and SoapySDR devices.
The problem was with rtl_tcp/RemoteTCPInput (remote rtl_tcp server) because it was the only case that failed.

Looking at RemoteTCPInput, its spectrum shows a large (+35dB above signal) spike/artifact located at the center frequency.
If I leave this spike centered on the FM station frequency, then the FM audio fails.
If I apply an offset frequency to the "Broadcast FM Demodulator" to move the spike away from the station frequency, then the audio works.
So the difference between the signal level and this spike/artifact peak is causing the audio problem.

Using the gain controls, both the RTL-SDR[0] and SoapySDR[1:0] devices can raise the signal level relative to this spike peak and thus achieve good FM audio.
Unfortunately, the RemoteTCPInput device gain controls have no effect on the signal level, so its FM audio remains poor.

Also, the RTL-SDR[0] and SoapySDR[1:0] devices offer a "Software DC block" and "Software IQ correction" options to reduce this spike relative to the signal.
Unfortunately, these options are missing from the RemoteTCPInput device.

Problem caused my missing "Bias T" issue:
I purchased a "Nooelec SAWbird+ NOAA Saw Filter & LNA Module" for use with the Satellite tracker, and discovered that the SoapySDR device was missing the "Bias T" option to power it (when using an RTL-SDR).

Request:
Please enable the gain controls and add the DC and IQ options on the RemoteTCPInput device when using rtl_tcp server.
Also, please add the missing "Bias T" option on the SoapySDR[1:0] device.

SYSTEM:

  Hardware: x86 64-bit
  OS:       Debian 11 (bullseye) 64-bit
  Hardware: Raspberry Pi 4B
  OS:       Raspberry Pi OS Lite (bullseye) 64-bit
  Dongle:   RTL-SDR + antenna
  SDRangel: (compiled from source following "https://github.com/f4exb/sdrangel/wiki/Compile-from-source-in-Linux")
    Version 7.7.0-58-gb5457541
    Build info: Qt 5.15.2 64 bits
    DSP Rx 16 bits    Tx 16 bits
      Included plugins for "Hardware dependencies":
        RTL-SDR
      Included plugins for "Soapy SDR":
        RTL-SDR
        Soapy Remote
@srcejon
Copy link
Collaborator

srcejon commented Oct 5, 2022

I'll take a look, but you might try running SDRangel on the Pi - then RemoteTCPInput will give you DC / IQ correction and a few other features that rtl_tcp doesn't support.

@f4exb
Copy link
Owner

f4exb commented Oct 6, 2022

Also, please add the missing "Bias T" option on the SoapySDR[1:0] device.

SoapySDR plugin shows controls exposed by SoapySDR so this control is missing from SoapySDR (one more among other shortcomings...) not from SDRangel.

@srcejon
Copy link
Collaborator

srcejon commented Oct 6, 2022

Not sure why rtl_tcp.exe isn't working. In its log, I see:

set gain mode 1
set gain 480

So the commands to set the gain are being received OK, but it doesn't seem to work, as I'd expect.

@srcejon
Copy link
Collaborator

srcejon commented Nov 3, 2022

The problem isn't actually with the gain control, but unsigned data being read as signed.

srcejon added a commit to srcejon/sdrangel that referenced this issue Nov 3, 2022
f4exb added a commit that referenced this issue Nov 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants