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.