Sentinel 2.00.05 full-time encrypted talkgroups

fpo701 · Jun 18, 2018

Hi!

I updated the Master DB for my BCDx86HP Sentinel today, along with all of my favorites lists. My favorites are exact copies of specific systems. In all of them, I run ID SEARCH.

One of the systems has a large chuck of talkgroups running Full-time encryption (https://www.radioreference.com/apps/db/?sid=1369). I noticed I was getting traffic on one of the IDs I knew was encrypted and in the DB.

I checked both the favorites list and the Sentinel DB. Both are missing any talkgroups marked as full-time encryption.

This is unfortunate for anyone running ID SEARCH. Even though RRDB knows the talkgroup description and function, it now has to individually be locked out as traffic on it appears.

Prior versions of Sentinel would import talkgroups running full-time encryption, as does the HP-1 version of Sentinel currently.

Is it by design that encrypted talkgroups are now no longer added to the local Master Database? Is there a way around this?

Thanks!

Thomas_Skoropad · Jun 18, 2018

fpo701 said:
Hi!

I updated the Master DB for my BCDx86HP Sentinel today, along with all of my favorites lists. My favorites are exact copies of specific systems. In all of them, I run ID SEARCH.

One of the systems has a large chuck of talkgroups running Full-time encryption (https://www.radioreference.com/apps/db/?sid=1369). I noticed I was getting traffic on one of the IDs I knew was encrypted and in the DB.

I checked both the favorites list and the Sentinel DB. Both are missing any talkgroups marked as full-time encryption.

This is unfortunate for anyone running ID SEARCH. Even though RRDB knows the talkgroup description and function, it now has to individually be locked out as traffic on it appears.

Prior versions of Sentinel would import talkgroups running full-time encryption, as does the HP-1 version of Sentinel currently.

Is it by design that encrypted talkgroups are now no longer added to the local Master Database? Is there a way around this?

Thanks!

Interesting, and I thought it was only me. Noticed the same for Thunder Bay ON after the database update last Monday June 11.
I’d like to know the answer as well.

fpo701 · Jun 18, 2018

I'm not sure how things have been this way. I had only been updating the master DB for travel prep lately, and only noticed this time because I did a complete refresh of my favorites.

N6ML · Jun 18, 2018

I hadn't noticed, but it's the same for the system that I monitor. I suppose maybe they figure that if you're using the global database, you probably wouldn't need to use ID search, but then if there are any new TGs that are not yet in the DB, you wouldn't be able to find them. Hmmm....

jonwienke · Jun 18, 2018

fpo701 said:
I checked both the favorites list and the Sentinel DB. Both are missing any talkgroups marked as full-time encryption.

This is unfortunate for anyone running ID SEARCH. Even though RRDB knows the talkgroup description and function, it now has to individually be locked out as traffic on it appears.

That is pointless, because having additional talkgroups programmed does not slow down scan speed. And it's bad form to memory hole a talkgroup just because somebody heard an encrypted transmission on it, and noted that in the DB.

kd7jfv · Jun 18, 2018

This doesn't seem to be limited to Sentinel, I just checked using ProScan import radioreference.com and it doesn't list any encrypted talkgroups either. Must be a rr.com database setting.

fpo701 · Jun 18, 2018

jonwienke said:
That is pointless, because having additional talkgroups programmed does not slow down scan speed. And it's bad form to memory hole a talkgroup just because somebody heard an encrypted transmission on it, and noted that in the DB.

It doesn't slow scan speed, but it does cause the scanner to "pause" on the talkgroup for a second when there's a transmission on that talkgroup even if it is encrypted.

kd7jfv · Jun 18, 2018

kd7jfv said:
This doesn't seem to be limited to Sentinel, I just checked using ProScan import radioreference.com and it doesn't list any encrypted talkgroups either. Must be a rr.com database setting.

I stand corrected about the ProScan import, I had the "don't import encrypted TGID channels" checked. I unchecked that box, reloaded data and it will import the encrypted talkgroups.

jonwienke · Jun 18, 2018

fpo701 said:
It doesn't slow scan speed, but it does cause the scanner to "pause" on the talkgroup for a second when there's a transmission on that talkgroup even if it is encrypted.

That pause happens anyway as the scanner processes the call grant from the control channel. The only additional time required is a few milliseconds to do the encryption check.

bemyax · Jun 18, 2018

I noticed Sentinel x36HP excludes those marked as encrypted whereas the HomePatrol version does not. About two weeks after encryption for law talkgroups went into effect on SARA https://www.radioreference.com/apps/db/?sid=6673 a dispatcher on Law Ops 2 flipped off her encryption off to do an attempt to locate. My recordings roll off after five days and I didn't think to preserve it. My point is that system encryption is not immutable, but catching a change for the database is a lot to ask of those providing the service.

fpo701 · Jun 18, 2018

jonwienke said:
That pause happens anyway as the scanner processes the call grant from the control channel. The only additional time required is a few milliseconds to do the encryption check.

True. There's always a pause as the radio is scanning. It needs that to decode enough of the control channel to check for active transmissions.

I just tested this a bit. For setup, make sure to be in ID search with a busy encrypted not locked out. Also make sure the delay time on the system is set to 2 seconds.

Allow for the "decode time".

The radio will open squelch when it detects a transmission on the encrypted talkgroup and audio will include a quarter second of encrypted garble audio.

Because squelch was opened, the radio now holds on the system for 2 additional seconds. This in effect slows down scanning.

I am able to consistently reproduce this on an SDS100. If the known encrypted talkgroups are in the radio DB assigned to an service type that isn't being monitored, then the transmission is completely ignored and the radio doesn't have the additional 2 second delay.

jonwienke · Jun 18, 2018

If the talkgroup is programmed, but is avoided or the service type is disabled, the scanner doesn't leave the control channel, or check whether encryption is in use, or delay on the voice channel.

N6ML · Jun 18, 2018

I just looked at the FLs that I had created by adding the system of interest from the global database, and they *do* have the encrypted channels. I created those FLs prior to the Sentinel update last week, so something apparently changed around that time - either in Sentinal (more likely?) or the Uniden DB....

jonwienke · Jun 18, 2018

The Uniden data pull from RR is filtering out encrypted channels, and IMO that is bad and pointless. Especially if encryption is being skipped by default.

jasonhouk · Jun 18, 2018

Bug has been submitted to software engineering.

Houk

u2brent · Jun 18, 2018

Entire systems are missing if they are full time E.

here's one.

https://www.radioreference.com/apps/db/?sid=4843

fpo701 · Jun 18, 2018

jonwienke said:
If the talkgroup is programmed, but is avoided or the service type is disabled, the scanner doesn't leave the control channel, or check whether encryption is in use, or delay on the voice channel.

That's the exact problem. The known encrypted talkgroups aren't in the database following performing the "Update Master DB".

I hate when I realize I didn't provide all the info needed. I tested your earlier assertion about the delay and discovered something. The system I originally reported it on is Type II. I sat on a P25 Phase I system (Ohio MARCS) for a bit. Most of Ohio State Patrol is running full encryption, so none of their talkgroups are in the latest master DB. The radio doesn't pause like it did on the P25. There's just a millisecond blip of the encrypted talkgroupID, no open squelch.

It appears the delay is less prominent on P25 system. Just food for thought.

Ensnared · Jun 19, 2018

Yes, I found a "DE" in Midland, Texas. Yet, I heard the conversation clear as day. I suppose I will need to submit a digital recording of such to convince those in charge of the Permian System to alter this to "De." Agreed. The RR DB is not always accurate.

buddrousa · Jun 19, 2018

That could mean possible encryption not fulltime.

fpo701 · Jun 19, 2018

Ensnared said:
The RR DB is not always accurate.

RRDB is only as accurate as the information provided to maintain it. The admins are here to work submissions created by users. The database is crowd-sourcing at it finest. If information is incorrect, that just likely means no one has submitted the correct information.

Sentinel 2.00.05 full-time encrypted talkgroups

OH DB Admin

Member

OH DB Admin

Member

More Info Coming Soon!

Member

OH DB Admin

Member

More Info Coming Soon!

Member

OH DB Admin

More Info Coming Soon!

Member

More Info Coming Soon!

Member

OAMPT

OH DB Admin

Member

Member

OH DB Admin

Similar threads