Settings Wrong?

[Jake Hill]

I've been waiting for the beta to come out and got everything compiled, no errors. I'm attempting to decode the following: https://www.radioreference.com/apps/db/?ctid=474 I have the newest beta sdrtrunk and JDME library, and they're showing loading correctly when chosen. I'm just wondering if there's a setting somewhere I'm missing? Double checked audio settings as well.

The control frequency is phase 1 and it tracks the other frequencies, but it won't decode phase 2. Am I missing something? This is all new to me and I have never messed with anything like this outside of some DMR decoding with DSDplus. Trunking is all new. Any help is much appreciated.

Thank you to the developers that make all of this possible!

73s!

-Jake

[Jake Hill]

Apologies, this is the correct link for the info: https://www.radioreference.com/apps/db/?sid=8427 

I've tried adding the frequencies and setting them as phase 2, still nothing. The control frequency decodes as phase 1 and trunks properly from what I can tell but no audio, and shows the traffic channels as phase 1. I hope this all makes sense.

[Hans]

Can you post your application log?

[Jake Hill]

Here is a pastebin: https://pastebin.com/ih1krgu5

I believe that is the log you're looking for?

On Saturday, November 23, 2019 at 8:30:57 PM UTC-5, Jake Hill wrote:

[sdrtrunk]

Jake,

It looks like you're using old code.

Please download the latest sdrtrunk 0.4.0 Beta 1 release (already compiled) here: https://github.com/DSheirer/sdrtrunk/releases/tag/v0.4.0-beta.1  (scroll down to the Assets sections to find the right version for your operating system)

How are you setting up your channel configuration for this system?  It looks like you have a number of TRAFFIC channels configured, which aren't necessary.  You should be able to setup just 1 channel configuration for the control channel frequency (854.8125 or 859.4375 or 859.9375 or 860.9375) and use the Phase 1 (not Phase II) decoder.  All Phase II trunked systems use a Phase 1 control channel.  The Phase II traffic channels will be automatically created as each call is detected on the Phase 1 control channel..

Denny

[Jake Hill]

Odd, I was using 0.4.0 Beta 1 release from that link. I downloaded again and tried, same issue. I added those channels to test before posting here. 854.8125 comes in clear as day and decodes, opens new traffic channels and shows the information but no audio. It shows the traffic channels as P1 in the now playing tab. I really appreciate the help!

On Saturday, November 23, 2019 at 8:30:57 PM UTC-5, Jake Hill wrote:

[DaveNF2G]

The system is probably Phase I, with information in the FCC license indicating Phase II authorization.  This triggers the "some talkgroups" notation on RR.

-Dave, NF2G

On Saturday, November 23, 2019 at 8:30:57 PM UTC-5, Jake Hill wrote:

[Jake Hill]

I was wondering if the information posted was questionable, is there any other troubleshooting I can do to figure out why I'm not decoding the audio?

Again, I really appreciate your time!

On Saturday, November 23, 2019 at 8:30:57 PM UTC-5, Jake Hill wrote:

[Hans]

The answer is right in your application log:

20191123 061611.422 [AWT-EventQueue-0] INFO  i.g.d.m.d.p.a.P25AudioModule - JMBE audio library path is NOT SET in your User Preferences. 
20191123 061611.422 [AWT-EventQueue-0] INFO  i.g.d.m.d.p.a.P25AudioModule - JMBE audio conversion library NOT FOUND 
20191123 061621.800 [sdrtrunk pool-1-thread-2] INFO  i.g.d.m.d.p.a.P25AudioModule - JMBE audio library path is NOT SET in your User Preferences.  

You need to build the JMBE library and then set the location of the jar file in the sdrTrunk preferences.

[Jake Hill]

That part of the log is from changing settings, if you look further down you can see it's set.

On Saturday, November 23, 2019 at 8:30:57 PM UTC-5, Jake Hill wrote:

[Hans]

I see now that you set the preference, but it still isn't loading the class.

Can you verify that the top line of the JMBE CHANGELOG file is "1.0.0 20191117 AMBE CODEC support"?

H

[Jake Hill]

It reads 1.0.0 20191117 AMBE CODEC support0.3.4.

On Saturday, November 23, 2019 at 8:30:57 PM UTC-5, Jake Hill wrote:

[Hans]

Did you see that this was a bug and fixed?  You'll need to redownload and recompile JMBE.

[Jake Hill]

Downloaded, compiled, and tried again. Still no audio. I have no idea what the issue could be. I suppose it's some weird system here or something. Oh well. Thank you to everyone for their help.

On Saturday, November 23, 2019 at 8:30:57 PM UTC-5, Jake Hill wrote:

[Jake Hill]

I left it running for awhile yesterday, and it picks up the emergency pages. I wonder if those are in real phase 1 and there's a hiccup somewhere in my setup causing it to think they're all phase 1?

On Saturday, November 23, 2019 at 8:30:57 PM UTC-5, Jake Hill wrote:

[sdrtrunk]

Jake,

For that system, you only need to setup one channel configuration for the control channel(s) using the Phase 1 (not 2) decoder, which it sounds like you were doing overnight.

When you select that channel in the 'Now Playing' window and select the 'Events' tab below, are you seeing Group or Individual call events being logged?  Look at the details to the right to see if it indicates that it couldn't setup a traffic channel to handle the call event.  Maybe you can post a screen shot with the events tab showing?

Regarding the emergency pages ... those always occur on the phase 1 control channel.  There won't be a phase 2 control channel.  Only the traffic channels use the phase 2 protocol and they are fully controlled (only) by a phase 1 control channel.

Denny

[Jake Hill]

Sorry for the delay, attached is a screen shot of the events. From what I can tell it's opening the correct traffic channels it's just not decoding the audio.

On Saturday, November 23, 2019 at 8:30:57 PM UTC-5, Jake Hill wrote:

[Ron Murray]

Looks like all of the group calls are encrypted. That's why you're not getting any audio.

[Jake Hill]

So I take it that means there's no way to listen to it?

On Saturday, November 23, 2019 at 8:30:57 PM UTC-5, Jake Hill wrote:

[Ron Webb]

That would be correct. I looked at the RadioReference page for the Lowndes County Public Safety P25 system, which lists all of the talkgroups as being in mode "DE", which means that it is encrypted digital audio. SDRTrunk only works if it is non-encrypted digital audio. I am not aware of any scanner that allows you to enter a digital decryption key. Decrypting encrypted audio without permission of the authority encrypting it is federal crime. Generally, that means you need a radio that is programmed by the same authority that programs the radios for the users of the system. Yes, it sucks when systems encrypt EVERYTHING. Thankfully, our sheriff and local police do see value in the public being able to listen to routine traffic, but do acknowledge that some traffic is "privilleged" information and shouldn't be broadcasted; for this, they reserve the right to encrypt as needed. Unfortunately, you aren't alone in having entire systems being encrypted. If you look at RadioReference Forums about scanners, you see the following notice:

Effective immediately we will be deleting, without notice, any negative threads or posts that deal with the use of encryption and streaming of scanner audio.

We've noticed a huge increase in rants and negative posts that revolve around agencies going to encryption due to the broadcasting of scanner audio on the internet. It's now worn out and continues to be the same recycled rants. These rants hijack the threads and derail the conversation. They no longer have a place anywhere on this forum other than in the designated threads in the Rants forum in the Tavern.

If you violate these guidelines your post will be deleted without notice and an infraction will be issued. We are not against discussion of this issue. You just need to do it in the right place. For example:
https://forums.radioreference.com/rants/224104-official-thread-live-audio-feeds-scanners-wait-encryption.html

[Jake Hill]

Dang, I get why they wouldn't want everyone listening though. Makes sense. I appreciate everyone's time!

On Saturday, November 23, 2019 at 8:30:57 PM UTC-5, Jake Hill wrote: