Skip to content
Denny Sheirer edited this page Dec 23, 2021 · 3 revisions

Denny's Notes on configuring and using RSP devices with the SDRplay API (v3.07 and v3.08)

My intended use case for the RSP devices is for VHF/UHF mobile radio monitoring and decoding in sdrtrunk. For the RSPduo, I intend to use the device as both a single tuner and as a dual-independent (ie master/slave) tuner. Most of my testing and observations stem from attempting to optimize the devices to this intended use case.

API

Non-Blocking vs Asynchronous vs Synchronous

The API is designed so that all methods/calls are non-blocking. Depending on how you intend to use the device, this is problematic.

Prior to initializing the tuners, most calls to set configuration details are immediate, since you're simply setting a memory value. Once you've initialized the device, you must invoke update to notify the API that you've changed each configuration detail. The update call returns immediately with a status value, however the API then applies the setting in an asynchronous manner and you'll be notified via the stream or device callback that the setting has changed. Moreover, you can't submit any more update requests to the API while this previous asynchronous operation is in progress, otherwise you'll get a FAIL or SERVICE BUSY status value from overlapping update calls.

There's at least two approaches that you can use, if you want to ensure your configuration changes are applied as requested:

  1. Repeatedly attempt (ie try/wait) to invoke the update() call until you get a SUCCESS response.
  2. Implement an update queue that ensures that only a single update request is in progress at a time, tracking each request to completion (via callback notification).

These approaches seem reasonable for a single-threaded environment, but not for a multi-threaded environment. So, be prepared to layer on functionality to manage and synchronize device and tuner configuration changes at runtime. It would be nice if the API had an optional asynchronous interface that could manage all of that for you.

RSPduo

RSPduo Modes

SINGLE TUNER

  • Access: only one of the Duo's tuners (1 or 2)
  • Sample Rates: all
  • Bandwidths: all

DUAL TUNER

  • Access: both tuners as a synchronized pair.
  • Both tuners use the same center frequency.
  • Sample Rates: all?
  • Bandwidths: all?

MASTER / SLAVE

  • Access: both tuners independently, one designated as master and the other as slave
  • Requires: a separate API instance for controlling each tuner (ugh!)
  • Sample Rates: 6MHz or 8MHz set via the DeviceT structure which is unique for the duo and separate from the normal way you set the sample rate, and where the 6/8 MHz is automatically decimated to a 2 MHz pre-decimation rate and you can specify an optionally specify a 1x, 2x, 4x, or 8x final decimation to get sub-multiples of 2MHz sample rates.
  • Bandwidths: 1.536 MHz

Note on RSPduo Sample Rate and IF Mode: the sample rate in master/slave mode is set via the RspDuoSamplingFrequency in the DeviceT structure and it seems to use a default of 6MHz with an IFMode of 1.620 MHz which produces an left-shifted, off-balance spectral display where instead of having a balanced filter roll-off on either end of the spectrum, the spectrum is shifted to the left so that the rolloffs are wrapped around and joined and produce a dip on the right hand side of the spectrum. If you set the sample rate to 8MHz, the IFMode is automatically set to 2.048 MHz and that setting produces a balanced (ie non-shifted) spectrum for both sample rates. So, either use the default of 6MHz and set the IFMode from the default of 1.6200 to 2.048, or set the sample rate to 8MHz and you get the (correct) IFMode of 2.048 by default. The only IFMode that produces the correct balanced rolloff in master/slave mode for both 6 and 8MHz samples rates is 2.048. The other modes (0, 450 and 1.620) all produce an erroneously left-shifted and wrapped (ie unbalanced) spectral output.

Note on Gain: I experimented with gain settings using both AGC mode and manually setting the LNA and Gain Reduction values. In the end, it seems that the default mode of AGC=enabled produces the best SNR for how I want to use it. I recommend experimenting with the various gain settings to see how the device performs for your intended use case.

Clone this wiki locally