SDRplay Support

[Sammy1Am]

These changes should provide basic support (see note 2) for SDRplay devices via the SDRplay API v3 (#933). There are no major breaking issues that I'm aware of, but there are some notes:

Notes:

1. I had to make two changes to build.gradle to make NetBeans (the IDE I'm using) happy with the project. If these break other IDEs I'm happy to remove those and keep them only locally, but if they don't cause issues they might help future NetBeans users.
2. I only have an RSP1, and even then I've only implemented a handful of the large number of features available through the SDRplay API. These changes should be enough to use any SDRplay device, but may not be enough to take full advantage of advanced features.
3. There are a couple questions around getSampleSize() and getBufferSampleCount(). It's wasn't entirely clear to me how these should be implemented for SDRplay devices. They seem to work fine as they are, but since I only guessed at the values, there may be unknown consequences elsewhere.
4. Changing the IF Mode setting breaks things. Since it was implemented already, I left it in there incase someone can make sense of it, but only IF_Zero mode works. (I think somehow changing the IF Mode shifts where frequencies are in the streams making it so sdr-trunk can't make sense of tuning anymore... But couldn't figure it out) If needed, I can disable that dropdown, but the default is IF_Zero and should work.
5. In order to connect to the SDRplay API, users will need to have installed version 3.07 (or later if they maintain backward compatibility) of the SDRplay API/Service, and make sure that the sdrplay_api library is on their path (e.g. in Windows they'd need to add C:\Program Files\SDRplay\API\x64 to their Path variable). If the library is inaccessible, an informational log printed to let them know SDRplay wasn't loaded, and then sdr-trunk should continue to load as normal (so that people who don't have/want SDRplay should be unaffected aside from the extra log entry)

Please let me know if there's anything else I can do to make this an easy merge. I don't anticipate these changes having any impact on existing non-SDRplay users, but that's hard for me to test and be sure. If any of the weirdness mentioned in the notes above has an obvious fix, I can make and test that too.

[Sammy1Am]

🔽 In regards to the conflict, using version = "15" should be fine. NetBeans just needed that version line to exist.

[DSheirer]

Awesome. I'll give this a test next weekend. I have The RSP 1, 1A and Duo I can test against.

[DSheirer]

I tested this morning with an RSP 1A. This was a first-time install of any sdrplay for me. I installed the Linux 3.07 driver, restarted the machine.

I plugged in the sdrplay.

I rebased your branch onto current master.

I launched sdrtrunk. It recognized the tuner and displayed data in the spectral display. After adjusting the sample rate and bandwidth and gain reduction, I think I mostly have it setup.

Some initial feedback:

1. It appears as if the spectral display is mirrored. This might be caused by your I/Q sample ordering in the buffers that you're providing. Depending on how sdrplay delivers the samples, you may have to interleave them yourself (in code).
2. You may want to tie the IF bandwidth to the sample rate so that the appropriate IF bandiwidth is automatically selected base on the sample rate. An enumeration is great for this.
3. You may want to present your sample rate values to the user in MHz. For example, 10.0 MHz is easier to read than 10000000
4. You should delay constructing the channel manager until the first channel source is requested and then deregister the channel manager from receiving samples once the last tuner channel source is released. This ensures that the polyphase channelizer does not run until it has to, when there is a demand for tuner channel sources.

[Sammy1Am]

Alright, well first of all, I'm really happy to hear it connected okay the first time. Most of my struggles were around wrapping / connecting to the API, so it's good to hear that that worked for at least one other person :P.

1. How mirrored are we talking? The I and Q samples are being delivered in small arrays, with one array for I and one for Q. I'm interleaving them myself by just putting i[0],q[0],i[1],q[1],etc. into an array. Do I have the Is and Qs switched for the interleaving? Am I reading them into the array the wrong way, or is the whole spectrum mirrored? And if the whole spectrum is mirrored and I need to reverse it, how can I tell when I have one-spectrum's worth of bits to reorder?

SDRplay sends data as it arrives, so I'm receiving ~1008 bytes of I/Q data per "packet". And I don't know if that just happens to be one-spectrum worth of data and I'm getting lucky, or if there's some magic happening somewhere to figure out which byte is the beginning of the spectrum. (This is where my lack of SDR knowledge is really showing).

Any pointers you can provide there would be helpful with that first item.

2-4. Good suggestions; makes sense to me.

Real-life has gotten pretty exciting for me lately, so it might be a bit before I get any updates in, but hopefully these should be quickish changes and I can get to them soon.

[DSheirer]

Mirroring: it seems to occur when you select an IF Mode other than IF_Zero. I don't know enough about sdrplay to know when would be the right time to use an IF offset of other than zero. If this causes mirroring, it might be something that should not be exposed to the end user in the context of a trunking decoder to avoid end user confusion.

I made a couple adjustments in the code:

1. SdrplayTunerController: In the stream callback, use 32767 instead of 2047 as the scaling factor for the I and Q samples. I recommend setting up a constant and then multiply each sample by the scalor constant:

private static final float SAMPLE_SCALOR = 1.0f / 32767f;

2. SdrplayTuner, set the sample bit size to 16.0 instead of 12.0 to get the spectral display to show the spectrum correctly in the vertical space.

[Sammy1Am]

My (very limited) understanding is that you'd use a non-zero IF offset to avoid certain types of interference, but I'm also not sure if they would be something that gets in the way of trunking signals (versus say, L-band or somesuch). Mirroring would explain why I couldn't quite figure out what happened to the signal when I chose a non-zero offset though. I'll try briefly to see if I can resolve the weird mirroring, but then I'll probably just disable that control.

[alphafox02]

So I pulled down your repo. Checked out the sdrplay branch. I then pulled down your other repo. Both repos sitting side by side.

I went into the sdrplay repo and edited the settings.gradle to include this,
includeFlat ‘SDRplayJava’ under what was already there.

It appears I’ve got a successful build.

[alphafox02]

I’ve tried both an rsp1a and an rspduo. Both are seen and show up within the GUI w/ 3.07 api installed. Both show about a two inch wide spike/orange area dead smack in the middle of the spectrum. On the rsp1a I can increase the if bandwidth along with the sample rate. I can also move the slider to the right on the RF gain slider and get what looks like a workable solution.

With the rspduo I’m not so lucky. It’s almost as if the if bandwidth and/or the sample rate are not working right. You really can’t see anything in the spectrum except about a 3/4 section of orange in the waterfall again towards the middle.

I’ll try out the rsp1a for now.

Edit: rsp1a works. I had no problems listening to a p25 phase 1 broadcast in the upper 800mhz range. Thanks!

[Sammy1Am]

SDRplayJava should get pulled from jCenter now so you won't need to check out both repos (unless you're trying to make changes to the SDRplayJava library).

I only have an RSP1, so I have limited troubleshooting help for your for the RSPduo (but I also super appreciate any data you can provide from it in case there's something I can fix/improve). A few notes that might help with troubleshooting (some of which will be improved once I follow DSheirer's recommendations above):

• The IF Bandwidth should be set to something similar to the Sample Rate. I've been using a Sample Rate of 5Mhz and IF Bandwidth BW_5_000 with success. Maybe try that on the RSPduo and see if it works okay? If your IF Bandwidth is smaller than the Sample Rate, you tend to get a big band right in the center (because the filter is removing the top and bottom).
• IF Mode should only ever be set to IF_Zero for now. Weird stuff happens on the other settings, I need to either fix that or disable it.
• I've only really been able to get things working with the RF Gain Reduction all the way left, but that setting is fairly frequency/hardware specific, so your mileage may vary (but maybe try far left with the RSPduo to see if it helps).

Glad the RSP1a is working at least though! Let me know if you figure anything out with the duo, and hopefully next week I'll have a little time to incorporate DSheirer's changes into this PR.

[alphafox02]

You know what it might be.. I’ll get you the details tomorrow, but at least with gr-soapy in gnuradio I remember having to specify the rx antenna as it was different then the rsp1a. I’m wondering if that’s the case with the standard api as well? I actually had the bandwidth and sample rate matched and messed around with the slider. I’ll document better tomorrow and take more screen shots.

[alphafox02]

Go to about 3:30, not sure if it’ll help but that’s the rspduo being setup in gnuradio. The antenna setting is not the standard rx.

https://youtu.be/7oYOZn4KWcY

[Sammy1Am]

Screenshots are always helpful! You're right about needing to specify the RX tuner though, it's the same in the standard API. Actually you have to "specify" (it's a little weird) the tuner even for the RSP1(a), so I've just hard-coded the tuner to always be Tuner A. Do you know on the RSPduo if you're expecting to use A or B? Can you check to see if Tuner A works (like is each connected to a separate antenna)? If it works okay on that tuner/antenna, then it's just a matter of supporting both tuners.

This might be a question for both @DSheirer and you: My understanding is that with an RSPduo, it's possible that both tuners can return streams simultaneously. When operating in this mode, it feels like sdrtrunk should treat each of the RDPduo's tuners as a "Tuner". I.e. in the Tuners tab you'd see both separately, and sdrtrunk could control them independently. Is this accurate?

I'll focus on getting the RSP1(a) support cleaned up and this PR done first before I add duo support, but perhaps I can use alphafox02 as a guinea pig for testing my changes there (unless someone wants to gift me an RSPduo ;P ;P )

[alphafox02]

Would anything here help?

https://github.com/szpajder/dumpvdl2#sdrplay-rsp-native-driver-version-3

Dumpvdl2 is using native sdrplay v3 api. I wonder if anything in the source would be of use?

https://github.com/szpajder/dumpvdl2/blob/master/src/sdrplay3.c

[alphafox02]

Wondering if for the duo it’s just needing the mode set? Like master vs slave etc?

[Sammy1Am]

Hmm, well the source linked does have this line:

case SDRPLAY_RSPduo_ID:
	fprintf(stderr, "%s: Cannot select antenna port: feature not supported\n",get_hw_descr(hwVer));
	return;

So I'm not sure it'll be specifically useful for the RSPduo 😜. Might come in handy more generally though, thanks!

I can see in the API where the duo's mode could be set, but in theory as long as it has a default mode, that's what's being used. It's not clear which mode is the default though. If you've got a Java IDE and feel like doing some debugging / digging, I can point you to the various lines and variables we could poke at to find out what's going on, but maybe in a separate thread in case it gets overly verbose. Otherwise, maybe try assuming that it's picked one of the modes and try to operate it as if it has? (Not sure, not familiar with RSPduo)

[alphafox02]

Can I get ahold of you privately? I'd like to see about getting you an RSPDUO.

[Sammy1Am]

You can send an email to [email protected] . We can chat more that way.

[ridencww]

Thank you @DSheirer for this great project and @Sammy1Am for the SDRPlay support. I built the sdrplay-support branch with Java 15 and it works great with the RSP2 Pro under Windows 10. Other than some speckles in the waterfall, P25 and P25-2 works extremely well and outperforms my Home Patrol 2. Now, I want to bring this up under a Raspberry Pi 4 and then revisit the sparkles.

[ThePatrickMartin]

Getting RSPDuo support would be awesome - especially if, as was mentioned earlier in this thread, the hardware tuners could be recognized as separate tuners inside SDRTrunk. I think that would make RSPDuo + SDRTrunk the de-facto standard for SDR trunking.

[ra1nb0w]

Any update about the merge? Anyway, thank you very much for the effort!

[Sammy1Am]

Closing this pull request in favor of #1040 which is more complete.

I will still try to get RSPduo support added as soon as I have time, but I've just finished moving and don't have a radio set up yet to do any testing (can't wait to see what I can pick up from the new house though!).