op25 with SDRplay rsp1a troubles

[nater3]

I recently upgraded from a NooElec dongle to an SDRplay rsp1a. I had the dongle working flawlessly with op25 in linux but am not having the same luck with the rsp1a.

I have the SDRplay 2.13 API installed along with SoapySDR. SoapySDRUtil --probe="driver=sdrplay" finds the device just fine.
This is where it gets weird and my lack of linux experience has me extremely frustrated. gqrx and op25 absolutely will not run with the device string "soapy=0,driver=sdrplay" and poo the bed with the following error:

fatal: soapysdr::device::make() no match

Don't ask me how I figured this out but gqrx runs just fine using SoapyRemote and the following string:

"driver=remote,remote=tcp://myserveriport,remote:driver=sdrplay,serial=191109CC97,soapy=3"

I'm fine running op25 with SoapyRemote if that's the way it has to be but I can't seem to figure out how to configure op25 correctly.
It connects to my SoapyRemote server and tunes to the frequency specified. I see activity on the Spectrum but it's just a giant spike on ANY frequency that I tune to. See photo.



Any ideas?
Thanks!

 

[wgbecks]

The FFT plot is of no value unless op25 is decoding (synchronized) the control channel. What you're seeing is nothing more than a bogus cached plot file that's meaningless. The FFT plots are of no value unless and until op25 is decoding and processing Trunk Signaling Blocks (tsbk's) as is evidenced by the presence of incrementing tsbk's counts in the console.

 

[boatbod]

Unfortunately I'm not too familiar with the required incantation to make soapy work, but theoretically anything that you can pass to gqrx should work the same for op25. It's going to go in the "--args" parameter and looking at the osmosdr code I think it needs to start with the word 'soapy'.

As long as the fft plot appears to be alive I think it's a fair bet that it's working properly. The big spike at the center middle suggests you need to do some offset tuning (-o 20000).

 

[nater3]

Unfortunately I'm not too familiar with the required incantation to make soapy work, but theoretically anything that you can pass to gqrx should work the same for op25. It's going to go in the "--args" parameter and looking at the osmosdr code I think it needs to start with the word 'soapy'.

As long as the fft plot appears to be alive I think it's a fair bet that it's working properly. The big spike at the center middle suggests you need to do some offset tuning (-o 20000).

I have tried with some offset tuning to no avail.

This seems like phantom a phantom FFT plot if that makes any sense?


Looks like this at any frequency...

I'm so confused.

 

[boatbod]

Yeah, if the plot doesn't change at all then it's likely the bug that wgbecks encountered. I've yet to find a way to reproduce it unfortunately.
Are you running the curses terminal or http? Is there anything in stderr.2 log that might give a clue?

 

[nater3]

Here's the log. A few errors but I don't know what to make of them.

gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.13.4
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
[INFO] SoapyRemote::setupRxStream(remoteFormat=CS16, localFormat=CF32, scaleFactor=32767, mtu=1500, window=44040192)
[INFO] Client side stream bound to 192.168.1.121:43453
[INFO] Client side status bound to 192.168.1.121:50958
[INFO] Using format CS16.
[INFO] Server side stream bound to [::ffff:192.168.1.121]:39288
[INFO] Server side stream connected to [::ffff:192.168.1.121]:43453
[INFO] Server side status connected to [::ffff:192.168.1.121]:50958
[1m[33m[WARNING] StreamEndpoint resize socket buffer: set 43008 KiB, got 1024 KiB[0m
[INFO] Configured sender endpoint: dgram=1452 bytes, 357 elements @ 4 bytes, window=1024 KiB
[1m[33m[WARNING] Set thread priority 0.5 failed: Operation not permitted[0m
[INFO] Client side stream connected to 192.168.1.121:39288
[INFO] Configured receiver endpoint: dgram=1452 bytes, 357 elements @ 4 bytes, window=43008 KiB
gain: name: IFGR range: start 20 stop 59 step 1
gain: name: RFGR range: start 0 stop 9 step 1
setting gain IFGR to 20
setting gain RFGR to 8
supported sample rates 250000-10000000 step 48000
Using two-stage decimator for speed=2400000, decim=25/4 if1=96000 if2=24000
p25_frame_assembler_impl: do_imbe[0], do_output[0], do_audio_output[0], do_phase2_tdma[0], do_nocrypt[1]
metadata update not enabled

 

[boatbod]

p25_frame_assembler_impl: do_imbe[0], do_output[0], do_audio_output[0], do_phase2_tdma[0], do_nocrypt[1]

Most significant items are:
do_imbe[0] <<< vocoder not enabled
do_audio_output[0] <<< voice decoding not enabled
do_phase2_tdma[0] <<< TDMA not enabled

It should look like this:

p25_frame_assembler_impl: do_imbe[1], do_output[0], do_audio_output[1], do_phase2_tdma[1], do_nocrypt[1]

Suggest you make sure you have "-V -2 -U" on your rx.py command line.
You probably also want to make sure logging is at least "-v 1" or higher.

 

[nater3]

Here's an updated log with your suggested changes

gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.13.4
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
[INFO] SoapyRemote::setupRxStream(remoteFormat=CS16, localFormat=CF32, scaleFactor=32767, mtu=1500, window=44040192)
[1m[33m[WARNING] StreamEndpoint resize socket buffer: set 43008 KiB, got 1024 KiB[0m
[INFO] Configured sender endpoint: dgram=1452 bytes, 357 elements @ 4 bytes, window=1024 KiB
[1m[33m[WARNING] Set thread priority 0.5 failed: Operation not permitted[0m
[INFO] Client side stream connected to 192.168.1.121:57236
[INFO] Configured receiver endpoint: dgram=1452 bytes, 357 elements @ 4 bytes, window=43008 KiB
gain: name: IFGR range: start 20 stop 59 step 1
gain: name: RFGR range: start 0 stop 9 step 1
setting gain IFGR to 20
setting gain RFGR to 8
supported sample rates 250000-10000000 step 48000
Using two-stage decimator for speed=2400000, decim=25/4 if1=96000 if2=24000
op25_audio:pen_socket(): enabled udp host(127.0.0.1), wireshark(23456), audio(23456)
p25_frame_assembler_impl: do_imbe[1], do_output[0], do_audio_output[1], do_phase2_tdma[1], do_nocrypt[1]
metadata update not enabled
audio device: default
set_buffer_size_near requested 4000, but returned 2730
Sp25_framer::rx_sym() tuning error +1200

 

[boatbod]

Last line of the log suggests incorrect tuning ("tuning error +1200"). Please post your pull rx.py command line. You may also want to try adding a "-X" to see if that helps.

 

[nater3]

./rx.py --args 'driver=remote,remote=tcp://192.168.1.121:55132,remote:driver=sdrplay,serial=191109CC97,soapy=3' -N 'IFGR:20,RFGR:8' -S 2400000 -x 2 -f 856.1875e6 -X -q .7 -o 17e3 -V -2 -U -v 1 2> stderr.2

 

[boatbod]

Was the -X in there previously, or did you just add it? If the latter, did it help at all?

Some thoughts:- ppm correction (-q) will not complain about floating point values, but only an integer is passed to the underlying driver. You might want to try -q 1 instead of 0.7.

What does your mixer plot (#5) look like?
Audio, if you ever see any "voice update" messages in the log, will be output via ALSA to the "default" device. Are you able to successfully play a .wav file using the 'aplay' command?

 

[nater3]

I've tried with and without the -X in there. No luck either way.
I'm not convinced that op25 is getting any data from the sdr.

Sorry, I'm not sure what you mean by 'aplay' command.

 

[nater3]

Image of control channel in gqrx.

 

[boatbod]

I've tried with and without the -X in there. No luck either way.
I'm not convinced that op25 is getting any data from the sdr.

Sorry, I'm not sure what you mean by 'aplay' command.

View attachment 83843

Sure looks like a big lot of nothing in the mixer plot.
op25 thinks it's tuned to 853.1875 but it's not showing the same signal as gqrx

 

[nater3]

I think I got it working!!
Changed N 'IFGR:20,RFGR:8' to N 'IFGR range:20,RFGR range:8'

But now I have no audio. lmao.
The fun never ends!

 

[nater3]

IT WORKS!!!!

 

[nater3]

Thanks so much for the help boatbod