segfault when running the application

When running the application I get a segfault.

To make sure my command line parameters where not the reason, I also tried the example as shown on the git page. All the following examples give a segfault error.

single_tuner_recorder -r 8e6 -b 6e6 -f 436e6 -o /dev/null 
single_tuner_recorder -r 8000000 -b 6000000 -f 436000000 -o /dev/null 
single_tuner_recorder -r 6000000 -i 1620 -b 1536 -l 3 -f 162550000 -o /dev/null
single_tuner_recorder -H -r 10000000 -i 0 -b 8000 -l 0 -f 371000000
single_tuner_recorder -L enabled -H -r 10000000 -i 0 -b 8000 -l 0 -f 371000000

Segmentation fault

The code is build on a Debian system running testing/trixie.

The hardware where this is tested, is an Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz, 256G Samsung SSD and 12G memory.

SDRPlay API service is up and running:

sudo systemctl status sdrplay.service 
● sdrplay.service - SDRplay API Service
     Loaded: loaded (/etc/systemd/system/sdrplay.service; enabled; preset: enabled)
     Active: active (running) since Mon 2023-12-25 05:23:47 CET; 8s ago
   Main PID: 230320 (sdrplay_apiServ)
      Tasks: 2 (limit: 14118)
     Memory: 396.0K
        CPU: 45ms
     CGroup: /system.slice/sdrplay.service
             └─230320 /usr/local/bin/sdrplay_apiService

Dec 25 05:23:47 seven systemd[1]: Started sdrplay.service - SDRplay API Service.
Dec 25 05:23:47 seven sdrplay_apiService[230320]: [230320]: sdrplay_apiService: sdrplay_apiServiceWorkerThread: Entry
Dec 25 05:23:47 seven sdrplay_apiService[230320]: [230321]: sdrplay_apiService_device: heartBeatThread: Entry

Going through some log files, I can across the following:

[Mon Dec 25 04:49:56 2023] single_tuner_re[227984]: segfault at 0 ip 00007f40f158e816 sp 00007ffddc351ad8 error 4 in libc.so.6[7f40f1444000+155000] likely on CPU 2 (core 1, socket 0)
[Mon Dec 25 04:49:56 2023] Code: 00 8b 0c 8a 8b 04 82 29 c8 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f1 89 f8 48 83 e1 3f 48 83 e0 3f 83 f9 30 77 3f 83 f8 30 77 3a <f3> 0f 6f 0f f3 0f 6f 16 66 0f ef c0 66 0f 74 c1 66 0f 74 ca 66 0f
[Mon Dec 25 04:50:56 2023] single_tuner_re[228039]: segfault at 0 ip 00007f152c98e816 sp 00007ffe260a4338 error 4 in libc.so.6[7f152c844000+155000] likely on CPU 2 (core 1, socket 0)
[Mon Dec 25 04:50:56 2023] Code: 00 8b 0c 8a 8b 04 82 29 c8 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f1 89 f8 48 83 e1 3f 48 83 e0 3f 83 f9 30 77 3f 83 f8 30 77 3a <f3> 0f 6f 0f f3 0f 6f 16 66 0f ef c0 66 0f 74 c1 66 0f 74 ca 66 0f
[Mon Dec 25 04:51:44 2023] single_tuner_re[228085]: segfault at 0 ip 00007efd8b58e816 sp 00007fff6e84e568 error 4 in libc.so.6[7efd8b444000+155000] likely on CPU 3 (core 1, socket 0)
[Mon Dec 25 04:51:44 2023] Code: 00 8b 0c 8a 8b 04 82 29 c8 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f1 89 f8 48 83 e1 3f 48 83 e0 3f 83 f9 30 77 3f 83 f8 30 77 3a <f3> 0f 6f 0f f3 0f 6f 16 66 0f ef c0 66 0f 74 c1 66 0f 74 ca 66 0f
[Mon Dec 25 04:52:35 2023] single_tuner_re[228133]: segfault at 0 ip 00007f6f84d8e816 sp 00007ffd67fd6398 error 4 in libc.so.6[7f6f84c44000+155000] likely on CPU 3 (core 1, socket 0)
[Mon Dec 25 04:52:35 2023] Code: 00 8b 0c 8a 8b 04 82 29 c8 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f1 89 f8 48 83 e1 3f 48 83 e0 3f 83 f9 30 77 3f 83 f8 30 77 3a <f3> 0f 6f 0f f3 0f 6f 16 66 0f ef c0 66 0f 74 c1 66 0f 74 ca 66 0f
[Mon Dec 25 04:53:10 2023] single_tuner_re[228161]: segfault at 0 ip 00007f7a60b6c816 sp 00007fff9587ca58 error 4 in libc.so.6[7f7a60a22000+155000] likely on CPU 0 (core 0, socket 0)
[Mon Dec 25 04:53:10 2023] Code: 00 8b 0c 8a 8b 04 82 29 c8 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f1 89 f8 48 83 e1 3f 48 83 e0 3f 83 f9 30 77 3f 83 f8 30 77 3a <f3> 0f 6f 0f f3 0f 6f 16 66 0f ef c0 66 0f 74 c1 66 0f 74 ca 66 0f
[Mon Dec 25 04:53:32 2023] single_tuner_re[228187]: segfault at 0 ip 00007f24d098e816 sp 00007fff2d1c5558 error 4 in libc.so.6[7f24d0844000+155000] likely on CPU 1 (core 0, socket 0)
[Mon Dec 25 04:53:32 2023] Code: 00 8b 0c 8a 8b 04 82 29 c8 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f1 89 f8 48 83 e1 3f 48 83 e0 3f 83 f9 30 77 3f 83 f8 30 77 3a <f3> 0f 6f 0f f3 0f 6f 16 66 0f ef c0 66 0f 74 c1 66 0f 74 ca 66 0f
[Mon Dec 25 05:05:16 2023] single_tuner_re[229089]: segfault at 0 ip 00007fd07098e816 sp 00007fff15d09e48 error 4 in libc.so.6[7fd070844000+155000] likely on CPU 1 (core 0, socket 0)
[Mon Dec 25 05:05:16 2023] Code: 00 8b 0c 8a 8b 04 82 29 c8 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f1 89 f8 48 83 e1 3f 48 83 e0 3f 83 f9 30 77 3f 83 f8 30 77 3a <f3> 0f 6f 0f f3 0f 6f 16 66 0f ef c0 66 0f 74 c1 66 0f 74 ca 66 0f
[Mon Dec 25 05:23:21 2023] sdrplay_apiServ[229268]: segfault at 7fbf63ffeeec ip 000055bc9ce070d1 sp 00007fbf69a1ce50 error 4 in sdrplay_apiService[55bc9ce00000+56000] likely on CPU 3 (core 1, socket 0)
[Mon Dec 25 05:23:21 2023] Code: 80 01 00 00 41 83 fc 10 0f 84 0b 03 00 00 49 8b 45 20 48 01 d8 48 8b a8 68 01 00 00 48 85 ed 74 d8 80 b8 78 01 00 00 00 75 cf <44> 8b 8d dc ce f9 00 45 85 c9 74 9b 44 8b 85 d0 cf f9 00 48 8d 15

libc information:

dpkg -l | grep libc6

ii  libc6:amd64                                    2.37-12                              amd64        GNU C Library: Shared libraries
ii  libc6:i386                                     2.37-12                              i386         GNU C Library: Shared libraries
ii  libc6-dev:amd64                                2.37-12                              amd64        GNU C Library: Development Libraries and Header Files

Maybe based on the behavior and information I shared you can point me in the right direction to try and solve this.

All the best,

Jan PE0SAT

Jan, thanks for giving a try.

I suspect the problem was caused by the antenna argument not being set (here I usually set "-a 'Antenna C'" with my RSPdx, so I never noticed this bug before).

The code is fixed now; please run 'git pull' and rebuild the program 'single_tuner_recorder', and hopefully all your examples should work without errors this time.

73, Franco

Franco,

I did a rebuild and some testing:

single_tuner_recorder -r 8e6 -b 6e6 -f 436e6 -o /dev/null

SerNo=1808027321 hwVer=2 tuner=0x01
SR=8000000 LO=436000000 BW=6 If=0 Dec=1 IFagc=0 IFgain=40 LNAgain=0
antenna=5 amPort=5
DCenable=1 IQenable=1 dcCal=3 speedUp=0 trackTime=1 refreshRateTime=2048
streaming for 10 seconds
total_samples=79860480 actual_sample_rate=8004883 rounded_sample_rate_kHz=8005
I_range=[-4042,4012] Q_range=[-4278,3813]

And strange to see this wasn't working:

single_tuner_recorder -r 8000000 -b 6000000 -f 436000000 -o /dev/null

sdrplay_api_Init() failed: sdrplay_api_Fail

just good to know, I guess related to 1000 versus 1024

Looking at the -h output I am confused on how to use the gain options. What is expected on the command line?

options:
    -s <serial number>
    -r <RSPduo sample rate>
    -d <decimation>
    -i <IF frequency>
    -b <IF bandwidth>
    -g <IF gain reduction> ("AGC" to enable AGC)
    -l <LNA state>
    -D disable post tuner DC offset compensation (default: enabled)
    -I disable post tuner I/Q balance compensation (default: enabled)
    -y tuner DC offset compensation parameters <dcCal,speedUp,trackTime,refeshRateTime> (default: 3,0,1,2048)
    -f <center frequency>
    -a <antenna>
    -x <streaming time (s)> (default: 10s)
    -o <output file> ('-' for stdout; 'SAMPLERATE' in the file name will be replaced by the estimated sample rate in kHz)
    -L enable SDRplay API debug log level (default: disabled)
    -T measure callback time difference only (no output) (default: disabled)
    -H get histogram of sample values (no output) (default: disabled)
    -h show usage

single_tuner_recorder -r 8e6 -g IFGR=35,RFGR=3,AGC=0 -b 6e6 -f 436e6 -o /dev/null

Maybe I can find some more in dept information looking for the SDRPlay API description

For an indefinite streaming time, I used -x -1 is that the best way to achieve this ? For -a do I use Antenna A or is there another value? What output is being used, CS16 and is possible to configure this.

Jan

Jan, the IF bandwidth is in kHz (these are the units used by SDRplay in their API for this specific parameter), therefore the correct way to specify the IF bandwidth is with '-b 6000'; you can see its value printed in the line where the sample rate ('SR=8000000') is also printed.

As per the gains, the SDRplay API actually thinks in terms of gain reductions (i.e. the higher the gain reduction value, the lower the gain), and uses two different parameters to specify them: the IF gain reduction (option '-g') that can go from 20dB to 59dB, and the so called 'LNA state', which is an integer index that goes from 0 (no RF attenuation) to a value that depends on the band you are listening to (see the section 'Gain Reduction Tables' on page 38 of the SDRplay API Specification Guide https://www.sdrplay.com/docs/SDRplay_API_Specification_v3.09.pdf). The LNA state is specified via the option '-l' (lowercase Lima).

For indefinite streaming time you can specify a very high value: for instance '-x 2000000000' (2 billion) should be good for more than 63 years.

For the RSP2 the antennas are called 'Antenna A', 'Antenna B', and 'Hi-Z' (see here: https://github.com/fventuri/single-tuner-experiments/blob/main/single_tuner_recorder.c#L312-L322); for other models they have different names; they are all listed in that code section.

The output is only in CS16 because that's the native format from the SDRplay API. If you are interested in other formats, you may want to look into my 'gr-sdrplay3' module for GNU Radio (https://github.com/fventuri/gr-sdrplay3) or in the extensions for csdr I wrote a while ago (https://github.com/fventuri/csdrx) if you use csdr, or something like SoapySDR (perhaps using it in a Python script).

Franco

Franco,

Thanks for sharing this information, I will investigate further. The main function to get this up and running is to measure satellite orbits using Doppler curves.

single_tuner_recorder -r 4e6 -b 6000 -g 35 -l 3 -x 7200 -f 436e6 -o - | rffft -f 436e6 -s 4e6 -c 50 -t 1 -q

Filename: stdin
Frequency: 436.000000 MHz
Bandwidth: 4.000000 MHz
Sampling time: 0.250000 us
Number of channels: 80000
Channel size: 50.000000 Hz
Integration time: 1.000000 s
Number of averaged spectra: 50
Number of subints per file: 60
Starting index: 0
SerNo=1808027321 hwVer=2 tuner=0x01
SR=4000000 LO=436000000 BW=6000 If=0 Dec=1 IFagc=0 IFgain=35 LNAgain=3
antenna=5 amPort=5
DCenable=1 IQenable=1 dcCal=3 speedUp=0 trackTime=1 refreshRateTime=2048
streaming for 7200 seconds
dropped 1512 samples
dropped 252 samples

And that will produce the following output (just s short time frame):

Source: STRF

The Antenna used is a small 70cm turnstile here is more on the hardware used.

Jan, I am really happy to hear that the little utility I wrote just to play with the SDRplay API is useful to others.

I started reading your web site about the world of satellites and the way to find their orbital parameters starting from Doppler effects is fascinating!

I definitely need to spend some time reading about it and learning how STRF works.

One quick comment (not sure if it matters for your work); if you use a sample rate of 4Msps, you should set the IF bandwidth to a value less than 4MHz (for instance 1536kHz with '-b 1536') to filter out frequencies outside the 4MHz window that could cause aliasing problems.

Franco

Franco,

The bandwidth and if part is indeed a subject that is causing some confusion.

Below a 2 hour recording at a 4e6 sample rate and as you can see not the whole bandwidth is visible. I saw somewhere in SDRPlay documentation that there is a relation between sample rate and usable bw and that not all bw values are possible.

This recording is below is using the following options:

single_tuner_recorder -r 4e6 -f 436e6 -b 6000 -g 35 -l 3 -x 172800 -o - the bw 6000 was my idea to get the whole 4e6 bandwidth, but as you can see it isn't.

What would be the best cli options to record the whole 70cm satellites part? this is between 435 - 438 Mhz and the commercial part is 400 - 404 MHz.

Jan, the SDRplay RSPs (like al the other SDR devices) have some hardware limitations that you need to be aware of.

For the RSP2 (which I think is the model you have) they are listed in the datasheet that you can find here: https://www.sdrplay.com/docs/RSP2_Datasheet.pdf

The most important ones (in the specifications section in the last page) are that the maximum sample rate is 10.66MHz and that the maximum throughput between the RSP2 and the PC (host in USB terms) where your client application runs is about 480Mb/s because of the USB 2 connection. This means that the higher the sample rate the lower the resolution of the I/Q samples in order to stay within that limit. If I remember correctly you get 14 bits at sample rates up to 6MHz and at 10MHz the resolution is only 8 bits.

Because of the first limitation you can't cover more than about 10MHz of bandwidth, i.e. you can't go from 400MHz to 438MHz (you may want to look into the Adalm Pluto or Pluto+ for that kind of bandwidth). The only thing you can do is to either choose one or the other of two subbands or have two RSPs with an antenna splitter.

For the commercial part I would use a center frequency of 402MHz, an IF bandwidth of 5MHz (-b 5000) and a little higher sample rate, like 6MHz (I think you still get 14 bits resolution at exactly 6MHz of sample rate).

For the 435-438MHz range, the central frequency would be 436.5MHz, IF bandwidth still 5000 and sample rate again 6MHz or somewhere around that.

Sample rates can be a little flexible and usually are somehow dictated by the client SDR application to try to lower the computational load (for instance FFT transforms prefer powers of two, so a sample rate of 5.76MHz might be easier than 6MHz).

Franco

fventuri / single-tuner-experiments

segfault when running the application #1