Add support for SDRplay RSP receivers

[fventuri]

John, I added support to linhpsdr for the SDRplay RSP receivers using the SoapySDR driver, since I saw you already have the RTL-SDR (and Lime Suite, I think) using SoapySDR.

A couple of comments:

• I added a few conditions 'radio->transmitter!=NULL' here and there, because the SDRplay RSP's do not have any transmitter, and that made linhpsdr crash in several places due to null pointers.
• also in create_receiver(), you had a block like this:

    case PROTOCOL_SOAPYSDR:
      if(radio->discovered->supported_receivers>1) {
        rx->adc=2;
      } else {
        rx->adc=1;
      }

  I am not sure why the second ADC is set to 2 (rx->adc=2) instead of 1 (since the first ADC has index 0) for the case of SoapySDR radios, when they support multiple receivers. I suspect that might be because of the way the Lime Suite enumerates its ADCs (but I am not sure because I don't have one), so I added the extra condition 'strcmp(radio->discovered->name,"lms7")==0':

    case PROTOCOL_SOAPYSDR:
      if(radio->discovered->supported_receivers>1 &&
         strcmp(radio->discovered->name,"lms7")==0) {
        rx->adc=2;
      } else {
        rx->adc=1;
      }

  Since I am not 100% (or even 50%) sure this is the right way to fix it, I put a comment there (line 1539), so you can review it, and decide how it should best handled.

Thanks, Franco Venturi - K4VZ

[joshuarubin]

I'm trying to use this patch, but (with or without this patch) I'm getting a segfault:

#0  0x00007f429c06cbf0 in __memmove_avx_unaligned_erms () at /usr/lib/libc.so.6
#1  0x00007f429844085b in SoapySDRPlay::readStream(SoapySDR::Stream*, void* const*, unsigned long, int&, long long&, long) () at /usr/lib/SoapySDR/modules0.8/libsdrPlaySupport.so
#2  0x00007f429ca3c3e5 in SoapySDRDevice_readStream () at /usr/lib/libSoapySDR.so.0.8
#3  0x000055c68591a190 in receive_thread (arg=0x55c685e85440) at soapy_protocol.c:276
#4  0x00007f429cc3a511 in  () at /usr/lib/libglib-2.0.so.0
#5  0x00007f429dbcd3e9 in start_thread () at /usr/lib/libpthread.so.0
#6  0x00007f429c007293 in clone () at /usr/lib/libc.so.6

I've tried using both the latest release and git versions of both soapysdr and soapysdrplay and can't get around this issue. Which versions of soapysdr and soapysdrplay are you using?

Edit, also getting lots of these errors before it segfaults:

full_rx_buffer: channel=0 fexchange0: error=-2

[fventuri]

Joshua, thanks for reporting this issue.

For SoapySDR I am using version 0.8.0 - I built it directly from the github repo back in December, and these are the last two commits I see:

git log
commit a489f3dca9d3ccd9b276b95a608ac3ef0299f635 (HEAD -> master, origin/master, origin/HEAD)
Merge: cdc8830 3492960
Author: Josh Blum <josh@joshknows.com>
Date:   Thu Dec 5 16:48:43 2019 -0600

    Merge pull request #247 from ncorgan/has-get_iq_balance_mode

    Device: added hasIQBalanceMode, getIQBalanceMode

commit cdc8830f4eee9fa9c883f018da2cfcc8f012dff9
Author: Josh Blum <josh@joshknows.com>
Date:   Thu Nov 28 23:24:47 2019 -0600

    Compatibility define for IQ balance mode API

For SoapySDRPlay I am using the version from here: https://github.com/SDRplay/SoapySDRPlay/tree/dual-tuner-submodes (please note that this is not the master branch, but the 'dual-tuner-submodes' branch, in order to be able to run the RSPduo as two independent receivers, as opposed to diversity reception) - I wrote that code too, so if there's a bug there, I can definitely help you with that.

I also saw crashes similar to the one you are reporting when the SDRplay API function 'sdrplay_api_Init()' fails for some reason. In that case the SoapySDRPlay driver should write out an error message like this:

error in activateStream() - Init() failed: ...

Another place to look at is your '/var/log/messages' file, because the SDRplay API writes messages there (especially if debug mode is turned on). These messages contain the string 'sdrplay', so you should be able to see them with grep sdrplay /var/log/messages.

Let me know what you find out, and we can go from there.

Franco

[joshuarubin]

Thanks for the help. I see this in the log before it segfaults:

sdrplay_api_Open
sdrplay_api_device: strmHandlerThread: Entry
sdrplay_api_device: eventHandlerThread: Entry
sdrplay_api_device: heartBeatThread: Entry
sdrplay_api_device: eventHandlerThread: Exit
sdrplay_api_device: strmHandlerThread: Exit
sdrplay_api_device: heartBeatThread: Exit
sdrplay_api_device: strmHandlerThread: Entry
sdrplay_api_device: eventHandlerThread: Entry
sdrplay_api_device: heartBeatThread: Entry

I tried switching to https://github.com/SDRplay/SoapySDRPlay/#branch=dual-tuner-submodes (as well as just plain https://github.com/SDRplay/SoapySDRPlay/) and had the same result. The main branch I've been using, though, is https://github.com/pothosware/SoapySDRPlay.

[joshuarubin]

I've found that by forcibly setting the sample rate to 10,000,000 things start to work. I'm running an RSP1A.

Rx sample rates: 250000.000000 -> 250000.000000 (5.208333),500000.000000 -> 500000.000000 (10.416667),1000000.000000 -> 1000000.000000 (20.833333),2000000.000000 -> 2000000.000000 (41.666667),2048000.000000 -> 2048000.000000 (42.666667),3000000.000000 -> 3000000.000000 (62.500000),4000000.000000 -> 4000000.000000 (83.333333),5000000.000000 -> 5000000.000000 (104.166667),6000000.000000 -> 6000000.000000 (125.000000),7000000.000000 -> 7000000.000000 (145.833333),8000000.000000 -> 8000000.000000 (166.666667),9000000.000000 -> 9000000.000000 (187.500000),10000000.000000 -> 10000000.000000 (208.333333),
sample_rate selected 10000000

Previously it was selecting 6,000,000

[fventuri]

Joshua, good find about the sample rate.

Last night before going to bed (I live in Florida), I updated SoapySDR to the latest code from git, and it worked for me, so it's probably not SoapySDR itself.

I ran all my tests using an RSPduo (unfortunately I don't have the RSP1A), and I was able to stream in 'linhpsdr' using any of the modes that RSPduo has.

I just took a quick look at the README for the repository you are using (https://github.com/pothosware/SoapySDRPlay), and, if I understand correctly, that SoapySDRPlay driver still uses the old version 2.X of the SDRplay API - all the work I've done is based on the newer version 3.X (I think the current version is 3.07) of the SDRplay API. Since the two major releases of the SDRplay APIs are significantly different, which version of the SDRplay API are you using when running 'linhpsdr'?

Also judging from the few 'sdrplay_api' messages from '/var/log/messages', I think you are running with the sdrplay_api debug mode turned off. To enable debug mode, edit the file 'Settings.cpp' in the source code for SoapySDRPlay: look for 'sdrplay_api_DebugEnable' (or something like that), and uncomment the line that enables verbose mode (and comment out the one that disables it); then recompile and reinstall the driver with debug mode enabled. The next time that 'linhpsdr' crashes, it should hopefully have much more information in '/var/log/messages', and that should help pinpoint the problem here (please be aware that having debug mode turned on adds some significant overhead when streaming, so eventually you may want to turn it back off, by reverting the source code change above, rebuilding it, and reinstalling it).

Franco

[frspin]

Same segmentation problem here with SDRPlay RSP1 with Ubuntu 18.04 and new Ubuntu 20.04. Segmentation error with SoapySDR 0.8 from GIT and with 0.7 from Ubuntu Repository. SoapySDRPlay from SDRPlay github and 3.07 API I have done manually all your correction and now startup segmentation error is gone. But now there is some GUI problems: no "Exit" button, no audio, no receiver configuration and many errors:

full_rx_buffer: channel=0 fexchange0: error=-2

And sometime, after this errors, segmentation error.

I have removed my sdrPlay.props file without any change in program behavior No messages in /var/log/syslog

On console, before full_rx_buffer messages, there is:

` soapy_discovery: get_info: sdrplay [INFO] devIdx: 0 [INFO] hwVer: 1 DriverKey=SDRplay HardwareKey=B0003P0007 soapy_discovery: hardware info key=sdrplay_api_api_version val=3,070000 soapy_discovery: hardware info key=sdrplay_api_hw_version val=1 Rx channels: 1 Rx channel full duplex: channel=0 fullduplex=1 Tx channels: 0 Rx sample rates: 62500,000000 -> 62500,000000 (1,302083),125000,000000 -> 125000,000000 (2,604167),250000,000000 -> 250000,000000 (5,208333),500000,000000 -> 500000,000000 (10,416667),1000000,000000 -> 1000000,000000 (20,833333),2000000,000000 -> 2000000,000000 (41,666667),2048000,000000 -> 2048000,000000 (42,666667),3000000,000000 -> 3000000,000000 (62,500000),4000000,000000 -> 4000000,000000 (83,333333),5000000,000000 -> 5000000,000000 (104,166667),6000000,000000 -> 6000000,000000 (125,000000),7000000,000000 -> 7000000,000000 (145,833333),8000000,000000 -> 8000000,000000 (166,666667),9000000,000000 -> 9000000,000000 (187,500000),10000000,000000 -> 10000000,000000 (208,333333), sample_rate selected 6000000 Tx sample rates: 62500,000000 -> 62500,000000 (1,302083),125000,000000 -> 125000,000000 (2,604167),250000,000000 -> 250000,000000 (5,208333),500000,000000 -> 500000,000000 (10,416667),1000000,000000 -> 1000000,000000 (20,833333),2000000,000000 -> 2000000,000000 (41,666667),2048000,000000 -> 2048000,000000 (42,666667),3000000,000000 -> 3000000,000000 (62,500000),4000000,000000 -> 4000000,000000 (83,333333),5000000,000000 -> 5000000,000000 (104,166667),6000000,000000 -> 6000000,000000 (125,000000),7000000,000000 -> 7000000,000000 (145,833333),8000000,000000 -> 8000000,000000 (166,666667),9000000,000000 -> 9000000,000000 (187,500000),10000000,000000 -> 10000000,000000 (208,333333), Rx bandwidths: 200000,000000, 300000,000000, 600000,000000, 1536000,000000, 5000000,000000, 6000000,000000, 7000000,000000, 8000000,000000, Tx bandwidths: 200000,000000, 300000,000000, 600000,000000, 1536000,000000, 5000000,000000, 6000000,000000, 7000000,000000, 8000000,000000, RX0: bandwidth=200000,000000 TX0: bandwidth=0,000000 Rx freq ranges: [10000,000000 Hz -> 2000000000,000000 Hz step=0,000000], Rx antennas: RX, Tx antennas: has_automaic_gain=1 has_automaic_dc_offset_correction=1 Rx formats: CS16, CF32, float=4 double=8 Sensors: Rx gains: IFGR 20,000000 -> 59,000000 step=0,000000 IFGain 20,000000 -> 59,000000 step=0,000000 RFGR 0,000000 -> 3,000000 step=0,000000 RFGain 0,000000 -> 3,000000 step=0,000000 Tx gains: IFGR 20,000000 -> 59,000000 step=0,000000 IFGain 20,000000 -> 59,000000 step=0,000000 RFGR 0,000000 -> 3,000000 step=0,000000 RFGain 0,000000 -> 3,000000 step=0,000000 main: discovery found 1 devices discovered: 0 device=8 adding sdrplay tree_selection_changed_cb tree_selection_changed_cb: selected=sdrplay,SoapySDR,3,07,�U, tree_selection_changed_cb: first=sdrplay,SoapySDR,3,07,�U, found 0

(linhpsdr:174886): Pango-WARNING **: 11:09:04.529: Invalid UTF-8 string passed to pango_layout_set_text()

(linhpsdr:174886): Pango-WARNING **: 11:09:04.538: Invalid UTF-8 string passed to pango_layout_set_text()

(linhpsdr:174886): Pango-WARNING **: 11:09:04.581: Invalid UTF-8 string passed to pango_layout_set_text()

(linhpsdr:174886): Pango-WARNING **: 11:09:04.605: Invalid UTF-8 string passed to pango_layout_set_text()

(linhpsdr:174886): Pango-WARNING **: 11:09:26.859: Invalid UTF-8 string passed to pango_layout_set_text()

(linhpsdr:174886): Pango-WARNING **: 11:09:26.885: Invalid UTF-8 string passed to pango_layout_set_text() `

And, after starting discovered device:

` starting LinHPSDR (Beta): sdrplay Soapy 3,07 �U

(linhpsdr:174886): Pango-WARNING **: 11:10:36.915: Invalid UTF-8 string passed to pango_layout_set_text() create_radio for sdrplay 8 loadProperties: /home/spin/.local/share/linhpsdr/sdrplay.props loadProperties: version=0,000000 expected version=2,000000 ignoring soapy_protocol_init soapy_protocol_init: SoapySDRDevice_make [INFO] devIdx: 0 [INFO] hwVer: 1 audio_get_backend_name: JACK audio: create_audio: USE_SOUNDIO: 1 JACK create_audio: soundio_connect_backend: unable to initialize audio backend create_receiver: channel=0 sample_rate=6000000 create_receiver: channel=0 frequency_min=10000 frequency_max=2000000000 create_receiver: buffer_size=1024 create_receiver: fft_size=2048 create_receiver: OpenChannel: channel=0 buffer_size=1024 sample_rate=6000000 fft_size=2048 output_samples=8 receiver_change_sample_rate: resample_step=1 receiver_update_title: LinHPSDR: sdrplay Rx-0 ADC-0 6000000 create_vfo: rx=0 soapy_protocol_create_receiver: setting bandwidth=1000000,000000 soapy_protocol_create_receiver: setting samplerate=6000000,000000 soapy_protocol_create_receiver: SoapySDRDevice_setupStream: channel=0 [INFO] Using format CF32. soapy_protocol_set_rx_antenna: set_rx_antenna: RX soapy_protocol_start_receiver: activate_stream soapy_protocol_start_receiver: create receive_thread soapy_protocol_start_receiver: receive_thread: id=0x5592370cb520 receive_thread: receive_thread x=-1 y=-1 radio_start rx_panadapter: resize_timeout full_rx_buffer: channel=0 fexchange0: error=-2 `

Any tip?

Regards

Franco Spinelli IW2DHW

[fventuri]

Franco, those segmentation fault problems are most likely due to a null pointer; a common case is when the 'linhpsdr' application tries to access the pointer to the TX part of the device, and since there is no transmitter on the RSPs, it fails with that error. In my patch I tried to guard against that problem by putting if's around that kind of code, so it wouldn't get called if the pointer to the transmitter is null, but I probably missed a few.

The best and easiest way to figure out where they happen and why is to compile 'linhpsdr' with all the debug symbols (just add the '-g' flag), run it, make sure it creates a core dump when it has a segmentation fault, and then use 'gdb' on the core dump to see where it crashed (I use the 'gdb' command 'where' to print that out; also 'gdb' is very useful to inspect the variable values that might have lead to the crash). If you need help with these steps, please let me know, and I'll be happy to answer your questions.

Ciao, Franco

[frspin]

I have done ulimit -c as suggested by John and this command give me 0 as answer So I need to change it to "unlimited" for getting a core file

After this I recompile with -g flag. Please show a detailed list of gdb command for finding useful information from gdb. I am completely new to gdb use!

Regards Franco Spinelli IW2DHW

[g0orx]

"ulimit -c unlimited" will let you get a core dump.

-- John

On Wed, 4 Nov 2020, 13:27 frspin, notifications@github.com wrote:

I have done ulimit -c as suggested by John and this command give me 0 as answer So I need to change it to "unlimited" for getting a core file

After this I recompile with -g flag. Please show a detailed list of gdb command for finding useful information from gdb. I am completely new to gdb use!

Regards Franco Spinelli IW2DHW

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/g0orx/linhpsdr/pull/84#issuecomment-721731099, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJEH5PJUR6ENND5S2QZEJ3SOFJFVANCNFSM4PYBFL4A .

[frspin]

OK Now, with core file (program recompiled removing -O3 and adding -g flag) I use gdb linhpsdr core and, as suggested by fventuri with "where" command I get:

[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". --Type for more, q to quit, c to continue without paging--c Core was generated by `./linhpsdr'. Program terminated with signal SIGSEGV, Segmentation fault.

0 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:384

384 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: File o directory non esistente. [Current thread is 1 (Thread 0x7f6a9e014700 (LWP 235255))] (gdb) where

0 __memmove_avx_unaligned_erms ()

at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:384

1 0x00007f6ab630850f in memcpy

(__len=<optimized out>, __src=<optimized out>, __dest=0x55eb004c9db0)
at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34

2 fexchange0

(channel=<optimized out>, in=<optimized out>, out=0x55eb004c9db0, error=<optimized out>) at iobuffs.c:496

3 0x000055eaff12c444 in full_rx_buffer (rx=0x55eb004c8600) at receiver.c:1246

4 0x000055eaff12c57a in add_iq_samples

(rx=0x55eb004c8600, i_sample=0.06964111328125, q_sample=-0.12481689453125)
at receiver.c:1268

5 0x000055eaff16f94a in receive_thread (arg=0x55eb004c8600)

at soapy_protocol.c:329

6 0x00007f6ab55d9931 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0

7 0x00007f6ab6429609 in start_thread (arg=)

at pthread_create.c:477

8 0x00007f6ab52af293 in clone ()

at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

I am very new to gdb command

Can I do other debug?

Regards

Franco Spinelli IW2DHW

[fventuri]

Franco, sorry for not being able to answer to you earlier, but during the weekday I use the same monitors for work, so I can switch to my Linux PC only after dinner (I live in Florida). From the stack trace, it looks like the problem could be around frame 3 in receiver.c

If you are very new to gdb, and have time this weekend (after 4pm your time), send me an email at <my github username>@comcast.net, and we can arrange to look into this issue together.

Franco

[frspin]

In Italy we are locked starting from tomorrow so I am at home! I will send you a mail at your email address and wait for your answer.

Franco Spinelli IW2DHW