OP25 Audio Issue

[Bubbarx]

Good Afternoon all,

After much work I appear to have gotten OP25 configured correctly so that it is monitoring my town's channels, however, I do not get audio from any of the talk groups it picks up. Looking at the log file I can't find any errors that stand out. The system sound is functioning correctly, tested it with another app. I have also made sure that it wasn't just encrypted channels that I wasn't receiving audio on. I am really at a loss at this point. I will upload a copy of the log shortly after it runs for a bit longer so there is more to go off of.

As an aside, for some reason, in order to actually receive the control channel, I have to use a frequency that isn't even listed as one of the primary channels in the database. 500.7954 vs the actual listed channels 500.4375, 500.5875, 500.8375

Computer is a MacBook Pro (2015)
OS is Ubuntu 18.04
When checking the sound settings the python pluggin shows up as an active sound application as: ALSA plug-in [python2.7]
As far as I can tell with the graphical plot, it appears to be tuned to the very peak as well.

Here is my current launch code
./rx.py --args 'rtl' -N 'LNA:47' -S 2400000 -f 500.7954 -o 25000 -q -2 -T trunk.tsv -v 1 -V -2 -U 2> stderr.2



Log:
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[R82XX] PLL not locked!
Using two-stage decimator for speed=2400000, decim=25/4 if1=96000 if2=24000
Project 25 IMBE Encoder/Decoder Fixed-Point implementation
Developed by Pavel Yazev E-mail: pyazev@gmail.com
Version 1.0 (c) Copyright 2009
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see the file ``LICENSE'' for details.
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[0]
Reading blacklist file
[R82XX] PLL not locked!
audio device: default
1540162111.265666 control channel timeout
1540162306.927546 voice update: tg(4001), freq(500437500), slot(-), prio(3)
1540162308.894927 voice update: tg(4001), freq(500437500), slot(-), prio(3)
1540162310.860017 voice update: tg(4001), freq(500437500), slot(-), prio(3)
1540162661.229738 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162663.466235 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162665.376601 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162667.455580 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162669.418792 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162671.438158 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162674.444861 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162686.894770 voice update: tg(4001), freq(502487500), slot(-), prio(3)
1540162688.914908 voice update: tg(4001), freq(502487500), slot(-), prio(3)
1540162691.043115 voice update: tg(4001), freq(502487500), slot(-), prio(3)
1540162693.063457 voice update: tg(4001), freq(502487500), slot(-), prio(3)
1540162695.248276 voice update: tg(4001), freq(502487500), slot(-), prio(3)
1540162697.490644 voice update: tg(4001), freq(502487500), slot(-), prio(3)
1540162720.751264 voice update: tg(4001), freq(502487500), slot(-), prio(3)
1540162723.046362 voice update: tg(4001), freq(502487500), slot(-), prio(3)
1540162725.067947 voice update: tg(4001), freq(502487500), slot(-), prio(3)
1540162727.303213 voice update: tg(4001), freq(502487500), slot(-), prio(3)

 

[Bubbarx]

Somehow someway I managed to get op25 to stop being able to pick up the control channel despite being right where it should be according to gqrx. This is driving me mad, haha.

Edit: Corrected the receive issue, still trying to figure out the audio problem.

 

[boatbod]

Audio configuration looks correct and is set to output to the "default" alsa device which is usually ok. Assuming you can play sounds with other applications (or maybe even the "aplay" utility) we shall assume that is not the problem.

One thing I find very curious is that there are voice updates for the same tgid every 2 seconds for the duration of the call. Normally you don't see updates for the same tgid while the app is actively playing audio on that same tgid.

1540162306.927546 voice update: tg(4001), freq(500437500), slot(-), prio(3)
1540162308.894927 voice update: tg(4001), freq(500437500), slot(-), prio(3)
1540162310.860017 voice update: tg(4001), freq(500437500), slot(-), prio(3)

1540162661.229738 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162663.466235 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162665.376601 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162667.455580 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162669.418792 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162671.438158 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162674.444861 voice update: tg(18001), freq(500437500), slot(-), prio(3)

I'd recommend increasing the log verbosity to -v 10 so we can really see what's going on in more detail.

At first guess I'm wondering whether this is a c4fm system rather than the default cqpsk modulation? If so, try setting -D fsk4 in the startup script and see if that makes any difference.

 

[Bubbarx]

Audio configuration looks correct and is set to output to the "default" alsa device which is usually ok. Assuming you can play sounds with other applications (or maybe even the "aplay" utility) we shall assume that is not the problem.

One thing I find very curious is that there are voice updates for the same tgid every 2 seconds for the duration of the call. Normally you don't see updates for the same tgid while the app is actively playing audio on that same tgid.

1540162306.927546 voice update: tg(4001), freq(500437500), slot(-), prio(3)
1540162308.894927 voice update: tg(4001), freq(500437500), slot(-), prio(3)
1540162310.860017 voice update: tg(4001), freq(500437500), slot(-), prio(3)

1540162661.229738 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162663.466235 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162665.376601 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162667.455580 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162669.418792 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162671.438158 voice update: tg(18001), freq(500437500), slot(-), prio(3)
1540162674.444861 voice update: tg(18001), freq(500437500), slot(-), prio(3)

I'd recommend increasing the log verbosity to -v 10 so we can really see what's going on in more detail.

At first guess I'm wondering whether this is a c4fm system rather than the default cqpsk modulation? If so, try setting -D fsk4 in the startup script and see if that makes any difference.

Here is the file: https://drive.google.com/open?id=1V6HzlG_jzHmeZc9WWofjJqosk-XMg8yl

Here is a second one I got while changing some settings: https://drive.google.com/open?id=1lDu13dIcz1TzfUL6wt01rzZQkSlaB7LE

I tried to switch the launch option to your suggest parameter but no luck on that front.

This is the system in question, in case you're curious https://www.radioreference.com/apps/db/?sid=712

 

[boatbod]

The second log is somewhat useful in as much as it shows that no voice framing is being received.

1540175978.737366 new tgid: 11004 Law Dispatch prio 3
1540175978.737476 new freq: 502.662500
1540175978.737507 voice update: tg(11004), freq(502662500), slot(-), prio(3)
1540175978.877734 NAC 0x4c1 TSBK: op=3d : 3d 00 03 22 d0 32 0a 25 10 a2 63 a0
1540175978.877804 NAC 0x4c1 TSBK: op=16 : 16 00 00 c0 4a 85 ff ff 00 01 17 b7
1540175978.877846 NAC 0x4c1 TSBK: op=05 : 85 90 40 80 00 00 00 00 00 00 68 de
1540175979.001706 NAC 0x4c1 TSBK: op=3c : 3c 00 00 34 cb 01 02 4c 7d 70 7f a4
1540175979.002552 NAC 0x4c1 TSBK: op=3a : 3a 00 00 34 cb 01 01 4a 01 70 68 53
1540175979.002588 NAC 0x4c1 TSBK: op=3b : bb 00 00 be e0 04 cb 4a 01 70 b5 67
1540175980.499125 voice timeout
1540175981.185977 NAC 0x4c1 TSBK: op=0b : 0b 90 00 00 00 00 00 00 4a 01 1a 11
1540175981.186240 NAC 0x4c1 TSBK: op=3c : 3c 00 00 34 cb 01 02 4c 7d 70 7f a4
1540175981.186307 NAC 0x4c1 TSBK: op=3a : ba 00 00 34 cb 01 01 4a 01 70 8c 67
1540175981.320045 NAC 0x4c1 TSBK: op=3b : 3b 00 00 be e0 04 cb 4a 01 70 51 53
1540175981.320326 NAC 0x4c1 TSBK: op=39 : 39 00 01 01 4a 93 04 49 ed 04 c3 35
1540175981.320494 NAC 0x4c1 TSBK: op=09 : 89 90 10 40 00 00 00 00 00 00 32 d1
1540175981.325011 NAC 0x4c1 TSBK: op=02 : 02 00 4a 93 2a fc 4a 93 2a fc e5 4e
1540175981.325067 NAC 0x4c1 TSBK: op=30 : 30 00 00 04 2a 25 56 14 f5 4a c3 f0
1540175981.325109 NAC 0x4c1 TSBK: op=33 : b3 00 23 38 40 64 0a 25 15 84 ac 7f
1540175981.325309 set tgid=11004, srcaddr=0
1540175981.325392 voice update: tg(11004), freq(502662500), slot(-), prio(3)
1540175981.386725 NAC 0x4c1 TSBK: op=33 : 33 00 33 a5 80 64 09 15 75 62 75 fc
1540175981.386948 NAC 0x4c1 TSBK: op=34 : 34 00 45 83 c0 64 05 96 bd 88 12 a3
1540175981.386997 NAC 0x4c1 TSBK: op=16 : 96 00 00 c0 4a 85 ff ff 00 01 f3 83
1540175981.598199 NAC 0x4c1 TSBK: op=02 : 02 00 4a 93 2a fc 4a 93 2a fc e5 4e
1540175981.598438 NAC 0x4c1 TSBK: op=30 : 30 00 00 04 2a 25 56 14 f5 72 74 ab
1540175981.598491 NAC 0x4c1 TSBK: op=3d : bd 00 03 22 d0 32 0a 25 10 a2 87 94
1540175981.598343 set tgid=11004, srcaddr=0
1540175981.739529 NAC 0x4c1 TSBK: op=3d : 3d 00 13 25 e0 32 09 15 75 62 1b 36
1540175981.739613 NAC 0x4c1 TSBK: op=33 : 33 00 23 38 40 64 0a 25 15 84 48 4b
1540175981.739657 NAC 0x4c1 TSBK: op=0b : 8b 90 00 00 00 00 00 00 4a 01 fe 25
1540175983.229260 voice timeout

Curiously the RRBD entry says this is a Phase 2 system, but everything I've seen in your logs says it's operating in Phase 1 (slot = "-").
Something seems off. When it's tuning a voice channel there appears to be no signal. Suggest you turn on plot #1 (FFT) and see whether it looks like the tuning line is centered over an active channel.

 

[Bubbarx]

The second log is somewhat useful in as much as it shows that no voice framing is being received.



Curiously the RRBD entry says this is a Phase 2 system, but everything I've seen in your logs says it's operating in Phase 1 (slot = "-").
Something seems off. When it's tuning a voice channel there appears to be no signal. Suggest you turn on plot #1 (FFT) and see whether it looks like the tuning line is centered over an active channel.

According to the plot it does look like it is switching to the active frequencies when it sees traffic, but it isn't switching on top of the voice channel. Unless its lagging and thats why it looks off? I'm not sure.

I'm gonna give this system a shot as well and see what happens: https://www.radioreference.com/apps/db/?sid=7232

Edit: Still no luck

 

[boatbod]

When it switches to a voice channel is the signal peak "nearby" or simply not there at all?
If it's nearby, it's quite possible you don't have PPM correction set up correctly.

Are you using any fine tune adjustments from the terminal?
Can you post some screen shots of (1) the terminal (2) the fft plot on the control channel (3) the fft plot on the voice channel.

Thanks