DSD+ 235 failing to auto L/O on P25 encryption

[M105]

Just installed 235 and noticed it was no longer locking out the encrypted sheriff channel. This is a Motorola P25 system. It shows a priority 50 and produces no audio but holds on the channel until the transmission stops. Shows KID=0000 and ALG=80 clear.

I switched back to 228 and it once agains L/Os the encrypted channel as it should.

 

[slicerwizard]

Did you check the settings in the menus?

 

[ScanRite]

Appears to have been turned on by default. Just turned it off and all is good. I do hear a few blips here and there, similar to my 536.

With it turned on, you see the Alg= and KeyID= data. Off you don't.

 

[M105]

Did you check the settings in the menus?

No I have not updated it in a while so I don't even know what menu you are referring to. I assumed just replacing the files as I have always done should work. I will take a closer look.

 

[M105]

Okay, I finally found the Follow Encrypted Voice Calls option in the menu of my P25 CC Event Log window. When I turn it off it does start working normally and L/O the encrypted sheriff channel. Problem is, it doesn't remember that setting. I had to restart this morning after a windows update and found it again following encrypted voice calls. After some testing I find that it defaults to enabled and does not remember on restarts that I changed it. I have the -e option included in the command line of DSD+ VC and CC.

How do I make it remember to L/O encrypted voice calls?

 

[mtindor]

I have the -e option included in the command line of DSD+ VC and CC.

There's your problem lady (tnx to South Main Auto on Youtube). Per dsdplus -h :

-e Follow encrypted voice

You do NOT want the -e option included in your command line.

MIke

 

[M105]

There's your problem lady (tnx to South Main Auto on Youtube). Per dsdplus -h :

-e Follow encrypted voice

You do NOT want the -e option included in your command line.

MIke

Well that's different. Appears to have done the deed though. Thanks!

 

[BM82557]

There's your problem lady (tnx to South Main Auto on Youtube). Per dsdplus -h :

-e Follow encrypted voice

You do NOT want the -e option included in your command line.

MIke

Notes.txt has -

DSD+ 2.71 New Features

Modified -e and 'E' handling;
If the user specifies that encrypted traffic should be muted, DSD+ will temporarily
lock out encrypted trunked P25 calls and will not tune VC FMPA/FMP24 to the calls.
On P25 systems with some encrypted groups, it is no longer necessary to lock out
all encrypted groups; just use -e on the command line or press 'E' to lock out all
encrypted calls.
This also enables monitoring of talkgroups that have a mix of clear and encrypted traffic.

Not sure of why there is a discrepancy

 

[M105]

Yeah I need to go read through all of it again. I had skipped the December update and only now took a notion to update everything. DSD+ works so well for what I am doing with it that I often just let it run for months without touching it. I do wish someone would re-write the documentation on it all so it wouldn't require so much searching through the changes.
---
One feature that I would like and have asked for before is to give DSD+ exclusive audio device control. I am monitoring two different systems and have to use 3 dongles, one VC and two CC. If I try to run two single dongles and both happen to be speaking at the same time I get the audio mixed together. The ability to give it exclusive audio device control isn't hidden in the changes is it?

 

[slicerwizard]

Can't you run two 1R instances and route the audio to different speakers?

-o<spec> Output audio device (1-255; 0=none) and channel (M/L/R) [-o1]

 

[M105]

Both speakers would still be active at the same time. With my current 3 dongle setup it works like a scanner since the VC can only select one file from the two CCs. It is a first come first serve situation. If DSD+ had the ability to take exclusive control of the audio device then the active and talking copy would essentially block any others that happen to talk at the same time. This would have the same effect and allow only one conversation to be on the speakers. Basically all I am asking for is DSD+ to take exclusive control of the audio device while it is outputting audio and relinquish that control when it stops.

 

[cg]

I run several copies of DSDPlus on one computer. I use -o1l in 1R batch file and -o1r in the 1Ra batch file. I can hear two conversations like I have a scanner at each end of the desk.
If one copy took exclusive control of the audio card, I wouldn't hear the second conversation. Seems to be backwards progress to get something to work using older options.

chris

 

[M105]

I run several copies of DSDPlus on one computer. I use -o1l in 1R batch file and -o1r in the 1Ra batch file. I can hear two conversations like I have a scanner at each end of the desk.
If one copy took exclusive control of the audio card, I wouldn't hear the second conversation. Seems to be backwards progress to get something to work using older options.

chris

The beauty of computer control is that we can make the switches optional so you can have two speakers at each end of your desk talking at the same time and I can have one output simulating a scanner. I actually have my output feeding into RadioFeed so I can listen (privately) remotely to my "scanner". So no, it isn't "backwards progress", rather it is making the software flexible enough to work in multiple scenarios.