• 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

BCDx36HP: Entry of Slot in Conventional systems

Status
Not open for further replies.

HogDriver

Member
Premium Subscriber
Joined
Feb 3, 2007
Messages
828
Location
Oklahoma City
#1
I will bring this up again as I’m seeing more of this occurring. Is it possible to put a column in Sentinal and other programming software to enter the Slot number when programming conventional DMR systems. I have at least two cases in my state where the same freq is used but one is Slot 1 and the other is Slot 2.

Just take a look at Okmulgee County in Oklahoma!


Sent from my iPhone using Tapatalk Pro
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,977
Location
Supply (Lockwood Inlet area), NC
#3
Uniden expects you to manually program this as a DMR One Frequency type system (a Uniden 'thing') - even though they don't do that for you with their own provided programming software. Of course, this is even more of a problem if using the full database.
 
Joined
Jul 18, 2014
Messages
8,884
Location
PA
#4
Uniden expects you to manually program this as a DMR One Frequency type system (a Uniden 'thing') - even though they don't do that for you with their own provided programming software.
Not true. DMR One Frequency Trunked is supported by RRDB (although those systems are labeled as "DMR Conventional Networked"), and that system type is imported into Sentinel as DMR One Frequency Trunked. Here's an example:
https://www.radioreference.com/apps/db/?sid=8699

The advantage to programming as One Frequency Trunked is that scanning is at least twice as fast. Each frequency is scanned once, rather than once for every slot and talkgroup ID permutation.
 

mikewazowski

Forums Manager/Global DB Admin
Staff member
Joined
Jun 26, 2001
Messages
10,681
Location
Central Ontario
#5
I will bring this up again as I’m seeing more of this occurring. Is it possible to put a column in Sentinal and other programming software to enter the Slot number when programming conventional DMR systems. I have at least two cases in my state where the same freq is used but one is Slot 1 and the other is Slot 2.

You'll have to use ProScan to convert those frequencies to One Frequency Trunked since Uniden ignores slot information from the database.

Or.... get a Whistler scanner which uses all the information in the database.

I took a look at the county and yes, those are conventional channels. Use ProScan to do what Sentinel can't or do it manually.
 
Last edited:

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,977
Location
Supply (Lockwood Inlet area), NC
#6
Not true. DMR One Frequency Trunked is supported by RRDB (although those systems are labeled as "DMR Conventional Networked"), and that system type is imported into Sentinel as DMR One Frequency Trunked. Here's an example:
https://www.radioreference.com/apps/db/?sid=8699


In some cases - in others, the entries are listed as conventional (because they are) and those when downloaded by Sentinel and loaded into a Uniden just don't work correctly. They work they way the are supposed to on a Whistler directly from the library with no user intervention required.
The advantage to programming as One Frequency Trunked is that scanning is at least twice as fast. Each frequency is scanned once, rather than once for every slot and talkgroup ID permutation.
This so-called "advantage" means absolutely nothing for conventional channels that are in the RRDB/library....at least on a Uniden.
 
Joined
Jul 18, 2014
Messages
8,884
Location
PA
#7
You'll have to use ProScan to convert those frequencies to One Frequency Trunked since Uniden ignores slot information from the database.

Or.... get a Whistler scanner which uses all the information in the database.

I took a look at the county and yes, those are conventional channels. Use ProScan to do what Sentinel can't or do it manually.
Or do a RR database submission with the frequencies specified as a "conventional networked" system, in which case the system will import into Sentinel as One Frequency automatically. If the system is submitted to RR as conventional freqs then it will download into Sentinel as conventional freqs. If it is submitted as "conventional networked", then it will download into Sentinel as a One Frequency Trunked system.

Regardless, if traffic on the frequency is segregated by slot or talkgroup, then it should be programmed a One Frequency. And if it is, whether because it is "conventional networked" in the RR database or converted from conventional to One Frequency with ProScan, it will scan at least twice as fast as the equivalent set of conventional frequencies.
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,977
Location
Supply (Lockwood Inlet area), NC
#8
Or do a RR database submission with the frequencies specified as a "conventional networked" system, in which case the system will import into Sentinel as One Frequency automatically.
Guess you just can't have the answer all the time - that has been done - and rejected.

Posting a complete trunk system for a frequency just because there are different dedicated users assigned to each slot is just dumb.
 

mikewazowski

Forums Manager/Global DB Admin
Staff member
Joined
Jun 26, 2001
Messages
10,681
Location
Central Ontario
#9
It's a conventional repeater that's not networked and the same group does not roam across slots hence the rejection.

Modifying the database because Uniden refuses to use slot and group info is against policy.

Uniden will either have to convert these conventional repeaters to OFT systems in Sentinel or their back end software or use the slot and group information as Whistler does.
 

HogDriver

Member
Premium Subscriber
Joined
Feb 3, 2007
Messages
828
Location
Oklahoma City
#12
I found a license, WRBP722, in Oklahoma County, Oklahoma, that belongs to the Oklahoma Zoological Society. I appears to be a OFT with 463.9625 operating as channel 1, on Slot 1, channel 2 on Slot 2, and the remaining frequencies as simplex direct. If I just add those direct channels to the frequency list of the OFT, will it still scan them and treat them as simplex?


Sent from my iPhone using Tapatalk Pro
 

DaveNF2G

Member
Premium Subscriber
Joined
Jan 23, 2001
Messages
9,084
Location
Rensselaer, NY
#13
You best solution appears to be to build the controversial systems on your own as a Favorite List with the correct parameters for your scanner. There are many drawbacks to simply scanning the database as downloaded.
 

UPMan

Uniden Representative
Premium Subscriber
Joined
Apr 19, 2004
Messages
13,263
Location
Arlington, TX
#14
If programmed as conventional and there are multiple slot and/or TGID differentiated users on that frequency, then each iteration in RRDB would result in a new OFT being made, for just that one slot/TGID. This results in many missed comms and inefficient scanning. Properly documented as an OFT (or DMR networked in RRDB), all traffic on the channel would be evaluated in one pass, not multiple passes.


The way RRDB is now caters to a Whistler scanner at the expense of Uniden scanners (and counter to how the system is actually used...if multiple user groups are on a DMR system, differentiated by TG and/or slot, this is trunked operation, not conventional).
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,977
Location
Supply (Lockwood Inlet area), NC
#15
You keep dragging this conversation to something other than the examples I've encounterd.

The examples I have are cases where a single licensed frequency became DMR and the licencee opted to use the two slots as dedicated "channels" independent of (no) talkgroups. A fixed user is on slot 1 and a different fixed user is on slot 2. This isn't a trunk system.

As far as catering - I believe Uniden is attempting to get RR to cater to Uniden with this OFT thing - purely a Uniden thing.
 
Joined
Jul 18, 2014
Messages
8,884
Location
PA
#16
I found a license, WRBP722, in Oklahoma County, Oklahoma, that belongs to the Oklahoma Zoological Society. I appears to be a OFT with 463.9625 operating as channel 1, on Slot 1, channel 2 on Slot 2, and the remaining frequencies as simplex direct. If I just add those direct channels to the frequency list of the OFT, will it still scan them and treat them as simplex?
If you have the system set to ID SEARCH, definitely. The simplex frequencies will still have something set for a talkgroup ID, though they may all use the same talkgroup ID. Log traffic for a while (ProScan works great for this) and you should be able to figure out which talkgroup/slot combos are used for various purposes and then program them accordingly.
 

UPMan

Uniden Representative
Premium Subscriber
Joined
Apr 19, 2004
Messages
13,263
Location
Arlington, TX
#17
Every DMR transmission occurs on an assigned TG. Some are also limited to a particular slot. To say that DMR conventional does not use TG is inaccurate. If you select "None" when programming the channel into an actual system transceiver, the TG is actually still assigned (to 0). Here is a citation for this from Whistler:


https://whistlergroup.com/pages/understanding-dmr-digital-mobile-radio said:
There are 6 different "flavors" of DMR. TalkGroupIDS (TGID) are used with all 6 flavors of DMR.

As Whistler has no capability of trunktracking DMR at this time, conventional is their only option. If at some point they add trunking capability, this functionality would benefit both manufacturers.


Any time a digital frequency has to be scanned multiple times to check for traffic for multiple TG or TG+slot combinations, the scanner is going to be ensured to miss more comms. Regardless of manufacturer.


Any time multiple user groups are sharing one or more frequencies and are differentiated by TG or TG+Slot, the operation is trunking.
 
Joined
Feb 18, 2013
Messages
1,375
Location
Nazareth, Pennsylvania
#18
Every DMR transmission occurs on an assigned TG. Some are also limited to a particular slot. To say that DMR conventional does not use TG is inaccurate. If you select "None" when programming the channel into an actual system transceiver, the TG is actually still assigned (to 0).
I have actually seen this in operation. There are several users in my area that are "part time" DMR users. Every TGID shows as 0 when they transmit, always slot 1 as far as I have seen.

I argued in favor of having TGID programming added to conventional in the Uniden, DMR, early days. I've since found that no matter what type of "conventional" system, OFT seems to work the best.
 

UPMan

Uniden Representative
Premium Subscriber
Joined
Apr 19, 2004
Messages
13,263
Location
Arlington, TX
#19
If one group is using 1 slot on 1 frequency, conventional would be equivalent to OFT. As soon as you add 1 more group (using a different slot or TG on that frequency), OFT is better.
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,977
Location
Supply (Lockwood Inlet area), NC
#20
I've since found that no matter what type of "conventional" system, OFT seems to work the best.

...OFT is better.
Of course on a Uniden OFT is going to be better on a Uniden because that's a Uniden "in between" thing (not conventional and not trunked). In their implementation they choose to ignore RRDB documented parameters for conventional channels so you get multiple entries of the exact same thing in the programming resulting in poor performance. I don't own it but I understand third party software vendors understand this and address it - Uniden simply is being stubborn and chooses to ignore it hoping RR "caters" to them.

If they believe OFT is so much better, then they should fix Sentinel to import properly (in their eyes) as a OFT system....like the third party vendors already do (as I am told).
 
Status
Not open for further replies.
Top