search

DSheirer / sdrtrunk

A cross-platform java application for decoding, monitoring, recording and streaming trunked mobile and related radio protocols using Software Defined Radios (SDR). Website:
GNU General Public License v3.0
1.6k stars 256 forks source link

"Do Not Monitor" Calls being decoded on P25 Trunking System #48

Closed Rylvir closed 8 years ago

Rylvir commented 8 years ago

On a P25 Trunking System (CQPSK), multiple talkgroups that are set to "Do Not Monitor" are being monitored and decoded occasionally.

DSheirer commented 8 years ago

Some questions:

1) When this happens, are you decoding the control channel and the do not monitor talkgroup is a channel grant, or are you decoding a traffic channel and the do not monitor talkgroup becomes active?

2) The Do Not Monitor alias that you setup, which Talkgroup Alias ID are you using, the talkgroup value (4 characters) or the radio ID (6 characters)?

3) Does the full conversation get played over the mixer/speakers, or does it appear that the audio manager recognizes that the talkgroup is flagged and stops the audio in mid-call?

4) In the 'Events' tab, how does the system classify the event: 'Call' or 'Call-Do Not Monitor'? Does the call event show the talkgroup in either the TO or FROM column, that you identified as a do not monitor talkgroup?

Thanks, Denny

Rylvir commented 8 years ago

1) Decoding a traffic channel for a monitored talkgroup and the do not monitor talkgroup becomes active at the tail of the regular group call 2) I am using the talkgroup value for alias id 3) It seems to recognize the talkgroup and stop the audio mid-call 4) In the events log the call shows up as a Group Call, with the talkgroup id showing in the TO column

DSheirer commented 8 years ago

I think this issue should be resolved with this commit: https://github.com/DSheirer/sdrtrunk/commit/ddfefe4b85afd61d27d8d33812b27924ee614da8

There were several instances where I was starting the audio before the TO/FROM metadata had been dispatched to the AudioManager, causing the audio to start before it had any of the aliases. I reordered the timing so that the AudioManager should get the correct metadata with the start of the call, so that it can better make the 'Do Not Monitor' determination.

Please advise if this issue persists after the next beta release (0.2.0.beta4).