SDRplay RSP1A experience... odd stuff, but with potential

[cfc62]

Some of you might remember that I'm in a challenging RF environment, with a couple of nearby VHF transmitters really making a mess out of things when they key up. Given that, when I saw support for the 14-bit RSP1A, I put getting one on my to-do list, and one arrived the other day.

14 bits should give another 6 db of headroom/dynamic range.

Not overly impressed with the packaging, but hey it's an SDR. Also, 2005 called and wants their USB port back. Seriously, where are the newer SDRs with better connectivity?

Nothing showed up in SDRTrunk when I inserted the cable... Tried a few other computers, all the same. Then got smart and downloaded the new SDRplay SDRconnect, and I could see the device works. It's "preview" level software, is really really limited and crashes a lot, but it does some good things.

Oh, that's right, we need an API to make this work in SDRTrunk - that's not on SDRT, that's on SDRplay. Oh, nuts, SDRplay only supports API version 3.12 and SDRT isn't there yet. They do offer older API versions, but installation isn't straightforward and required some help on the Discord (thanks err!). Also didn't like that the USB description for the device is "Vendor-Specific Device" with no other information.

One important thing to note, the sample depth (10, 12 or 14 bits) of the RSP1A depends on your sampling rate. You only get the full 14 bits between 2 MSPS and 6.048 MSPS. Foreshadowing....

Fired up an 800 MHz P25 PII system, and... it worked! For a while. However, it would lose CC lock all the time. I then noticed that it lost lock after SDRT readjusted the base frequency. Either it just doesn't like shifting the base frequency, or something else is at play here.

I then extended the bandwidth to the highest possible, and since it didn't shift base frequency then, it was more stable - but not completely so.

I then tried VHF NBFM, which is why I bought the thing in the first place.

Initial results were quite good. I think I can tell there's more headroom when I'm using the lower sample rates, but it's not easy to quantify. But nearby transmitters don't cause as much havoc as before - but there are still issues.

What has really thrown me for a loop is the increasing audio delay when using the lower sampling rates (1.5, 3.0).

What happens is that the time between the signal actually occurring and the audio being played gets longer and longer and longer. At one point the audio was 8 MINUTES behind. The spectral display is real time, but both the audio and channel spectrum are increasingly delayed.

I replicated this 4 times.

I went down to processing and listening to 1 single channel and this still happened, repeatably. The audio sounds fine, it's just delayed, and again that delay increases over time. First starting SDRT it's pretty much on time, but even within a minute it can be 10-15 seconds behind, and 5 minutes later it can be well more than a minute behind.

Went back to a lower sampling rate, and the increasing delay re-occurred.

I switched to the highest sample rate, and this issue is not present. This issue also not present on AirSpy.

Weird stuff. No memory leaks seen, no excessive CPU, just... increasingly delayed audio. Haven't tried generating recordings yet.

Also, turning on IF ACG doesn't work very well, but I need to research that more.

[cfc62]

Oops, I'm seeing a memory leak now that I've let it run longer...

[cfc62]

Great, this SDR is off by 1.3 ppm, or 1 KHz at 850 MHz. That's terrible.

Also finding that in SDRconnect, even with ACG turned off, it still applies it. Super, I love unpredictable behavior. :^(

[DSheirer]

Resolved: #1695

[DSheirer]

@cfc62 Thanks for the inputs. There's definitely a memory leak in sdrtrunk when running RSP tuners and even more so when running RSP tuners at a reduced sample rate.

I have this fixed and I'm testing right now. I'll try to push out a new release today (0.6.0 beta 4) ... if you could test it again?

[cfc62]

Of course!

As a followup, the RSP1A is... driving me nuts. This isn't on SDRT, but there's all sorts of weird behavior from this unit, even when using SDRplay and SDRconnect. That is, I think much of this is hardware ACG doing weird things, even when supposedly set to off.

• Seems like ACG is running to some extent even when explicitly turned off (as I noted above)
• Noise floor can decrease when turning gain up, and vice-versa (again, with AGC off)
• Overload flashes when... there's no overload (see this across apps)
• Leaving 20-30 db of headroom on AGC reduces the utility of having 14 bit depth by a huge amount
• Even with this headroom, it gets wiped out when a local TX lights up
• Wideband noise bursts on frequency and gain changes
• Odd behavior when running 0 db gain
• Outside of fast ACG, there are times when the gain suddenly drops 10-15 db and I only notice because all of my NBFM channels go silent (power squelch settings are now set far too high to unsquelch)

Fun!

[cfc62]

So, one fun thing I've noticed from the RSP1A data sheets:

LNA gain "slider settings" are BACKWARDS.

That is, the 0 (zero) LNA slider setting is the MAXIMUM gain.

And 8 LNA slide setting is the MINIMUM gain.

Who does this?

Denny, you might want to invert the LNA slider in SDRTrunk for this SDR.

Also, in the data sheet it implies a curve but if these are discreet settings then that makes no sense:

They also neglect to mention which SDR ADC chip they're using. Might have to break this thing open at some point.

Here are the gains, NFs and IIP3 for one band (420):

[cfc62]

I'll note here that I understand that SDRplay folks are quoting specs when the RSP1A is used in conjunction with the SDRplay software, which I have more ill feelings towards.

In this way, it's hard to pull apart what's done natively in the SDR hardware portion, and what's tweaked in the SDRplay software part.