OP25 Playing audio on OP25 when src=0

[mtindor]

@KA1RBI, @boatbod, @lukekb

I'm trying to monitor a P25 C4FM system (American Electric Power). This is a new system just coming online. The vast majority of traffic is patches (from their current EDACS system to the P25 system). If I listen on a scanner, I can hear the patch traffic. But the patch traffic is not played on OP25 (and subsequently not on Trunk Recorder either if I test that).

Example in the logs -- OP25 doesn't even attempt to play this, so I'm guessing it is not attempting to decode it (is it because src=0) ? Like I said, it is a patch from EDACS to P25. If an actual P25 subscriber radio on the P25 system transmits, I will hear that. But I won't hear the traffic that comes back through the EDACS-->P25 patch even though the audio is clearly being sent over 856.3375.

Feb 18 11:17:11 i5 op25[13455]: 1582042631.153686 voice update: tg(2220), freq(856337500), slot(0), prio(3)
Feb 18 11:17:11 i5 op25[13455]: 1582042631.203226 set tgid=2220, srcaddr=0
Feb 18 11:17:11 i5 op25[13455]: 1582042631.426723 set tgid=2220, srcaddr=0
Feb 18 11:17:11 i5 op25[13455]: 1582042631.562714 set tgid=2220, srcaddr=0
Feb 18 11:17:12 i5 op25[13455]: 1582042632.654442 voice timeout
Feb 18 11:17:13 i5 op25[13455]: 1582042633.200729 set tgid=2220, srcaddr=0
Feb 18 11:17:13 i5 op25[13455]: 1582042633.200780 voice update: tg(2220), freq(856337500), slot(0), prio(3)
Feb 18 11:17:13 i5 op25[13455]: 1582042633.250157 set tgid=2220, srcaddr=0
Feb 18 11:17:13 i5 op25[13455]: 1582042633.337788 set tgid=2220, srcaddr=0
Feb 18 11:17:13 i5 op25[13455]: 1582042633.473396 set tgid=2220, srcaddr=0
Feb 18 11:17:13 i5 op25[13455]: 1582042633.474410 set tgid=2220, srcaddr=0
Feb 18 11:17:13 i5 op25[13455]: 1582042633.475011 set tgid=2220, srcaddr=0
Feb 18 11:17:14 i5 op25[13455]: 1582042634.702635 voice timeout
Feb 18 11:17:15 i5 op25[13455]: 1582042635.249531 set tgid=2220, srcaddr=0
Feb 18 11:17:15 i5 op25[13455]: 1582042635.249635 voice update: tg(2220), freq(856337500), slot(0), prio(3)
Feb 18 11:17:15 i5 op25[13455]: 1582042635.299580 set tgid=2220, srcaddr=0
Feb 18 11:17:15 i5 op25[13455]: 1582042635.385320 set tgid=2220, srcaddr=0
Feb 18 11:17:15 i5 op25[13455]: 1582042635.385975 set tgid=2220, srcaddr=0
Feb 18 11:17:15 i5 op25[13455]: 1582042635.521674 set tgid=2220, srcaddr=0
Feb 18 11:17:15 i5 op25[13455]: 1582042635.522677 set tgid=2220, srcaddr=0
Feb 18 11:17:15 i5 op25[13455]: 1582042635.661529 set tgid=2220, srcaddr=0
Feb 18 11:17:16 i5 op25[13455]: 1582042636.750871 voice timeout
Feb 18 11:17:17 i5 op25[13455]: 1582042637.297050 set tgid=2220, srcaddr=0
Feb 18 11:17:17 i5 op25[13455]: 1582042637.297110 voice update: tg(2220), freq(856337500), slot(0), prio(3)
Feb 18 11:17:17 i5 op25[13455]: 1582042637.347105 set tgid=2220, srcaddr=0
Feb 18 11:17:17 i5 op25[13455]: 1582042637.433322 set tgid=2220, srcaddr=0
Feb 18 11:17:17 i5 op25[13455]: 1582042637.569548 set tgid=2220, srcaddr=0
Feb 18 11:17:17 i5 op25[13455]: 1582042637.570136 set tgid=2220, srcaddr=0
Feb 18 11:17:17 i5 op25[13455]: 1582042637.570916 set tgid=2220, srcaddr=0
Feb 18 11:17:18 i5 op25[13455]: 1582042638.798805 voice timeout

As you can see, here we are referencing TG 2220. If I listen on a scanner, I hear the traffic shown above. If I monitor it in DSDPlus, it says src=EXTERNAL and I believe DSDPlus will decode it as well.

For some reason OP25 is ignoring this though. Any thoughts?

Mike

 

[mtindor]

@KA1RBI , @lukekb, @boatbod

To be clear on this, I am sending audio output over UDP to another computer running VLC.

./rx.py --nocrypt -2 --args 'rtl=0' --gains 'lna:45' -S 960000 -T jctrunk.tsv -l http:192.168.0.109:8383 -f 856312500 -D fsk4 -U -2 -u 23456 -w -W 192.168.0.107 -v 9

I don't have any other PHase II systems to test on. But I can easily send the audio from Phase I systems over UDP.

So I don't know if this is an issue with it ignoring src=0, or if it's an issue with my commandline not being correct for decoding Phase II / sending it to VLC.

Mike

 

[mtindor]

@KA1RBI, @lukekb, @boatbod

Ignore this post. This is a total non-issue. The whole problem was that I accidentally added -U to the commandline, thus also enabling the built in UDP player. I removed that, and I'm getting sound now.

Mike

 

[boatbod]

Curiously you also seem to be hitting a lot of voice timeouts at the 2 second mark which is characteristic of using the "-D fsk4" command line option to select c4fm modulation when you'd be better off letting it run in cqpsk mode.

 

[mtindor]

Curiously you also seem to be hitting a lot of voice timeouts at the 2 second mark which is characteristic of using the "-D fsk4" command line option to select c4fm modulation when you'd be better off letting it run in cqpsk mode.

Thanks for mentioning that. I figured if I had C4FM in trunk.tsv and all I was monitoring was C4FM sites, then forcing it on commandline isn't going to hurt anything. But now that you mentoined that, I think I remember a buddy of mine telling me that even though a standalone P25 site might be C4FM, if there is PHase II activity (and in this case it is PHase II), the voice channels would be operating in DQPSK or something like that.

So I removed -D fsk4 from the commandline, and I modified my trunk.tsv file to be CQPSK for those PHase II sites I'm monitoring. Hopefully that'll help. Because despite me saying I was getting audio, I still hadn't heard any actual audio. I just assumed that my issue was with the -U switch when I wasn't monitoring audio locally on the machine.

Anyway, we'll see how it goes. Thanks

Mike

 

[boatbod]

Thanks for mentioning that. I figured if I had C4FM in trunk.tsv and all I was monitoring was C4FM sites, then forcing it on commandline isn't going to hurt anything. But now that you mentoined that, I think I remember a buddy of mine telling me that even though a standalone P25 site might be C4FM, if there is PHase II activity (and in this case it is PHase II), the voice channels would be operating in DQPSK or something like that.

So I removed -D fsk4 from the commandline, and I modified my trunk.tsv file to be CQPSK for those PHase II sites I'm monitoring. Hopefully that'll help. Because despite me saying I was getting audio, I still hadn't heard any actual audio. I just assumed that my issue was with the -U switch when I wasn't monitoring audio locally on the machine.

Anyway, we'll see how it goes. Thanks

Mike

The modulation parameter in trunk.tsv only has effect in a very rarely used configuration that most people don't need to worry about. The -D parameter is the primary way of setting c4fm for Trunked P25. P25 Phase 2 voice channels requires qpsk modulation to be received properly, so any system that has at least *some* ph2 tgids present (which yours does, since slot=0 in your logs above) should always be configured for cqpsk regardless.

Note: any time you need to remove the -U to skip the local audio player you probably want to also add -V to enable the voice codec. If you don't do this, the "audio" you'll hear will be garbled static as the app will be streaming raw P25 signaling frames for the wireshark protocol decoder. Placing a -V enables the codec and causes 8khz PCM samples to be streamed instead.

 

[mtindor]

The modulation parameter in trunk.tsv only has effect in a very rarely used configuration that most people don't need to worry about. The -D parameter is the primary way of setting c4fm for Trunked P25. P25 Phase 2 voice channels requires qpsk modulation to be received properly, so any system that has at least *some* ph2 tgids present (which yours does, since slot=0 in your logs above) should always be configured for cqpsk regardless.

Note: any time you need to remove the -U to skip the local audio player you probably want to also add -V to enable the voice codec. If you don't do this, the "audio" you'll hear will be garbled static as the app will be streaming raw P25 signaling frames for the wireshark protocol decoder. Placing a -V enables the codec and causes 8khz PCM samples to be streamed instead.

It's working great now. Thanks for the tips!

mike

 

[marklt1]

The modulation parameter in trunk.tsv only has effect in a very rarely used configuration that most people don't need to worry about. The -D parameter is the primary way of setting c4fm for Trunked P25. P25 Phase 2 voice channels requires qpsk modulation to be received properly, so any system that has at least *some* ph2 tgids present (which yours does, since slot=0 in your logs above) should always be configured for cqpsk regardless.

Note: any time you need to remove the -U to skip the local audio player you probably want to also add -V to enable the voice codec. If you don't do this, the "audio" you'll hear will be garbled static as the app will be streaming raw P25 signaling frames for the wireshark protocol decoder. Placing a -V enables the codec and causes 8khz PCM samples to be streamed instead.

Can we still stream 8khz PCM through the wireshark port with the current builds?
I use this stream to capture the audio, post-process, and eventually archive it to file. That has worked perfect for almost 2 years now until this past March. I thought I read in some other posts about this being unsupported or depreciated.
Previously, I could open up a UDP listener, capture the data, and then close the listener writing the stream to a file. The raw stream would be between 20KB and 80KB on average. Now it appears to limit itself to blocks on 9KB. I was curious as if the format or sizing would have changed for the liquidsoap enhancement.

Below is my command line

./rx.py --args 'rtl' --gains 'lna:36' -S 2560000 -f 800e6 -D cqpsk -n -g 100 -x 4.0 -l http:0.0.0.0:8080 -q 0 -o 25000 -T ./realtime.tsv -V -2 -w -W 10.1.1.3 -u 23181 -v 2 2> /var/log/scanner.log


realtime.tsv

"Sysname" "Control Channel List" "Offset" "NAC" "Modulation" "TGID Tags File" "Whitelist" "Blacklist" "Center Frequency"
"GCRCN ALL - Cleveland Simul (Greater Cleveland Radio Communications Network) " "856.1625,856.1375,855.9875,855.9625" "-25" "0x491" "CQPSK" "trs_7337.tsv" "56520,56521,56522,56538,56539,56540,56541,56542" "" ""

Thanks, Mark

 

[marklt1]

Can we still stream 8khz PCM through the wireshark port with the current builds?
I use this stream to capture the audio, post-process, and eventually archive it to file. That has worked perfect for almost 2 years now until this past March. I thought I read in some other posts about this being unsupported or depreciated.
Previously, I could open up a UDP listener, capture the data, and then close the listener writing the stream to a file. The raw stream would be between 20KB and 80KB on average. Now it appears to limit itself to blocks on 9KB. I was curious as if the format or sizing would have changed for the liquidsoap enhancement.

Below is my command line

./rx.py --args 'rtl' --gains 'lna:36' -S 2560000 -f 800e6 -D cqpsk -n -g 100 -x 4.0 -l http:0.0.0.0:8080 -q 0 -o 25000 -T ./realtime.tsv -V -2 -w -W 10.1.1.3 -u 23181 -v 2 2> /var/log/scanner.log


realtime.tsv

"Sysname" "Control Channel List" "Offset" "NAC" "Modulation" "TGID Tags File" "Whitelist" "Blacklist" "Center Frequency"
"GCRCN ALL - Cleveland Simul (Greater Cleveland Radio Communications Network) " "856.1625,856.1375,855.9875,855.9625" "-25" "0x491" "CQPSK" "trs_7337.tsv" "56520,56521,56522,56538,56539,56540,56541,56542" "" ""

Thanks, Mark

Adding on to my last question, I may have found another issue causing the above problem, but I wanted to confirm the 8khz PCM stream hasn't changed.

 

[boatbod]

Stream away! If you specify -w -V op25 will stream raw 8khz S16LE audio to the -W destination of your choice.
Obviously you don't want to have -U as that would also enable the internal audio player which would mess up your streaming.

The only thing deprecated (albeit not yet removed) is support for Wireshark decoding. If you specify -w but don't specify -V then wireshark data will be streamed, but it's kinda useless because the wireshark plugin is really old and only support Ph1 FDMA messaging.