BUGS: SDRangel RPI server using SDRplay RSP1A

[gvimlag]

SYSTEM:

  Hardware-0: x86 64-bit                        (Client)
  OS-0:       Debian 11.7 (bullseye) 64-bit     (Client)

  Hardware:   Raspberry Pi 4B                   (Server)
  OS:         Raspberry Pi OS (bullseye) 64-bit (Server)
  SDR:        SDRplay RSP1A connected to Raspberry Pi 4B

  SDRangel: (compiled from source following "https://github.com/f4exb/sdrangel/wiki/Compile-from-source-in-Linux")
    Version 7.15.4-56-ge83d97444
    Build info: Qt 5.15.2 64 bits
    DSP Rx 24 bits    Tx 16 bits

The SDRangel Raspberry Pi server has several bugs/issues when using the SDRplay RSP1A device. If I'm doing something wrong, please let me know.

BUGS/ISSUES:

1. Without the WORK-AROUND (see below); the Pre-fill buffer takes ~40 seconds to fill and the waterfall never starts.
2. "LNA Gain" is stuck at "0.0dB". It can NOT be altered.
3. When using the "Broadcast FM demodulator" to listen to FM radio, if the "Remote device sample rate": a) is DECREASED from "2,000,000 S/s" to "1,000,000 S/s", then the audio playback pitch drops an octave (audio playback speed likely cut in half). Playback pitch is restored by returning to "2,000,000 S/s". b) is INCREASED from "2,000,000 S/s" to "3,000,000 S/s", then the audio playback PERMANENTLY stops. It is NOT recovered by returning to "2,000,000 S/s". To recover audio playback, the server must be stopped and restarted.
4. When using the "Broadcast FM demodulator" to listen to FM radio, the "IQ Sample bit depth" must be set to "24 bits" to get clear stable audio. "8 bits" has static. "16 bits" has less static. "24 bits" is clear and stable. "32 bits" is clear, but has occasional stuttering.
5. "MW/FM (Enable MW/FM notch filter)" on RSP1A is missing.
6. "DAB (Enable DAB notch filter)" on RSP1A is missing.
7. "Decimation factor (applied on remote device)" defaults to "2". Prefer that it default to "1" for clearer audio. (Also, WORK-AROUND below requires setting it to "1").
8. "Pre-fill" defaults to "1 second". Prefer that it default to "0.1 second" so that setting changes are observed more quickly.

The most severe bug is getting the client to connect reliably to the server.

To reproduce this bug, first determine the local IP address of the Raspberry Pi server. In the example below, it is "192.168.0.123".

Next, start the SDRangel server on the Raspberry Pi with the following commands:

  rm -rf ~/.config/f4exb      #start clean
  rm -rf ~/.local/share/f4exb #start clean
  /opt/install/sdrangel/bin/sdrangelsrv         \
    --remote-tcp                                \
    --remote-tcp-address 192.168.0.123          \
    --remote-tcp-port    1234                   \
    --remote-tcp-hwtype  SDRplayV3              \
    --remote-tcp-serial  <RSP1A serial number>
  <WAIT FOR SERVER TO COMPLETE STARTUP: wisdom file, etc.>

Finally, start a "RemoteTCPInput Rx device" on the X86_64 Debian client:

  rm -rf ~/.config/f4exb      #start clean
  rm -rf ~/.local/share/f4exb #start clean
  /opt/install/sdrangel/bin/sdrangel
    Add Rx device->RemoteTCPInput
      OK
    start/stop acquisition

FAIL: The waterfall never starts. The pre-fill buffer takes ~40 seconds to completely fill, empties, then repeats.

I've found a fix/work-around.

WORK-AROUND: Start a RemoteTCPInput Rx device on the X86_64 client:

  rm -rf ~/.config/f4exb      #start clean
  rm -rf ~/.local/share/f4exb #start clean
  /opt/install/sdrangel/bin/sdrangel
    Add Rx device->RemoteTCPInput
      OK
    Dec: 1                  <- Change "Decimation factor (applied to remote device)" from 2 to 1
    start/stop acquisition  <- 1st click
    start/stop acquisition  <- 2nd click *BEFORE* pre-fill buffer fills!
    start/stop acquisition  <- 3rd click

SUCCESS: The waterfall starts. The pre-fill buffer completely fills in 1 second and stays full.

Please let me know if I'm doing something wrong. Also, please let me know if I can help with anymore info or testing.

[srcejon]

1. Without the WORK-AROUND (see below); the Pre-fill buffer takes ~40 seconds to fill and the waterfall never starts.

Yes, I noticed something odd with this the other day, so needs looking at.

4. When using the "Broadcast FM demodulator" to listen to FM radio, the "IQ Sample bit depth" must be set to "24 bits" to get clear stable audio. "8 bits" has static. "16 bits" has less static. "24 bits" is clear and stable. "32 bits" is clear, but has occasional stuttering.

What does the signal look like? Does it help to use the channel gain setting?

5. "MW/FM (Enable MW/FM notch filter)" on RSP1A is missing.
6. "DAB (Enable DAB notch filter)" on RSP1A is missing.

Yes, and probably wont be implemented. It's too complicated to support every different option for every SDR in the one client. You could control these via the Web API if needed.

7. "Decimation factor (applied on remote device)" defaults to "2". Prefer that it default to "1" for clearer audio.
8. "Pre-fill" defaults to "1 second". Prefer that it default to "0.1 second" so that setting changes are observed more quickly.

You should be able to use the new Plugin Presets to set your own defaults.

[gvimlag]

"What does the signal look like?" IQ: 8 bits -> carrier is barely visible

IQ: 16 bits -> carrier is slightly more visible

IQ: 24 bits -> carrier is more visible

IQ: 32 bits -> carrier is visible

"Does it help to use the channel gain setting?" Increasing "Ch Gain" makes the static worse for all 4 cases.

[srcejon]

Decimation setting isn't being set on remote at startup, due to a race condition, which is probably the cause of the initial buffering problem.

[srcejon]

3. When using the "Broadcast FM demodulator" to listen to FM radio, if the "Remote device sample rate": a) is DECREASED from "2,000,000 S/s" to "1,000,000 S/s",

The SDRplay doesn't support sample rates lower then 2MS/s, so if you try to adjust the remote device sample rate to 1MS/s, it will quite possibly go wrong. To reduce the rate lower than this, you need to use decimation.

[gvimlag]

The SDRangel client (RemoteTCPInput) allows me to set the "SR (remote device sample rate)" to "1,000,000 S/s".

I just did a test. The SDRangel client (RemoteTCPInput) allows a sample rate from "00,000,000 S/s" to "99,999,999 S/s". So there is no range checking in this client.

[srcejon]

So there is no range checking in this client.

Correct.

edit: Have just written something basic.

[srcejon]

2. "LNA Gain" is stuck at "0.0dB". It can NOT be altered.

SDRplay API has an index setting, rather than gain in dB, so this would need to be changed.

[srcejon]

"Does it help to use the channel gain setting?" Increasing "Ch Gain" makes the static worse for all 4 cases.

Do you have the AGC button pressed? If not, what IF gain setting are you using?

[gvimlag]

"Do you have the AGC button pressed? If not, what IF gain setting are you using?" The AGC button is NOT pressed (DEFAULT setting). I'm using the 0dB (DEFAULT) IF gain setting.

[srcejon]

Ok, press AGC of set IF to -50ish, as you would if using it directly. At 0, the ADC will be overloaded, if it's anything like the Duo. You may need to experiment, but easiest just to enable AGC. (Note this maps to IF AGC for SDRplay)

[gvimlag]

"Ok, press AGC of set IF to -50ish, as you would if using it directly. At 0, the ADC will be overloaded, if it's anything like the Duo. You may need to experiment, but easiest just to enable AGC. (Note this maps to IF AGC for SDRplay)"

AGC=ON. IF=0.0dB. Test: Increasing Ch Gain from 0dB to 100dB. IQ: 8 bits -> 0dB: very noisy signal, >0dB only STATIC IQ: 16 bits -> 0dB: less noisy signal, >9dB only STATIC IQ: 24 bits -> 0dB: clean signal, >15dB only STATIC IQ: 32 bits -> 0dB: clean/stutter signal, >45dB only STATIC

AGC=OFF. IF=-50.0dB. Test: Increasing Ch Gain from 0dB to 100dB. IQ: 8 bits -> 0dB: very noisy signal, >9dB only STATIC <- Improved: 0dB vs 9dB IQ: 16 bits -> 0dB: less noisy signal, >9dB only STATIC IQ: 24 bits -> 0dB: clean signal, >15dB only STATIC IQ: 32 bits -> 0dB: clean/stutter signal, >48dB only STATIC <- Slightly improved: 45dB vs 48dB

NOTES: At Ch Gain=0db: IF=-50.0dB gives better signal than AGC=ON for 8 &16 bits IQ cases.

[srcejon]

To clarify, keep "channel gain" fixed at 0, and eperiment with IF gain setting

To find the correct setting, it's probably better to do this with the SDRplay device connected localy, not via Remote TCP.

[gvimlag]

"To clarify, keep "channel gain" fixed at 0, and eperiment with IF gain setting" I believe that you want me to locate the best signal for "IQ: 8 & 16 bit" by only varying the "IF", with "AGC=OFF". Test Results: NOTE-1: I believe changes in atmospheric conditions (much hotter than during prior measurements) accounts for the baseline noise changes. "AGC=OFF" & "Ch Gain=0dB" IQ: 8 bits -> best signal (slightly noisy) @ "IF<-40dB" ("IF=-59dB only STATIC) IQ: 16 bits -> best signal (slightly noisy) @ "IF<-40dB" ("IF=-59dB only STATIC) IQ: 24 bits -> best signal (clean) @ "IF<-53dB" ("IF=-59dB still good signal) IQ: 32 bits -> best signal (clean/stutter) @ "IF<-59dB" ("IF=-59dB still good signal) Observation-1: For "IQ: 8 & 16 bit", examining the waterfall's VISIBLE background noise across the 2MHz spectrum shows a noticeable jump @ "IF > 40db". Observation-2: For all "IF" settings, "IQ: 24 & 32 bit" have lower audio noise than "IQ: 8 & 16 bit".

"To find the correct setting, it's probably better to do this with the SDRplay device connected localy, not via Remote TCP." Locally, there is no "IQ: ? bit" option to test. Also, locally: The signal is always clean, no stuttering, no problems. Good signal with both "IF AGC" ON or OFF. Good signal with "IF AGC: OFF", over full range of "IF: 00 to -59".