• 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.
Joined
Jul 18, 2014
Messages
8,884
Location
PA
#21
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.
You have it exactly backwards. The whole point of OFT is to AVOID poor performance by not scanning the same frequency repeatedly with various permutations of slot and talkgroup settings. Which is exactly what happens when you scan conventional channels tagged with talkgroup and/or slot info. Programmed OFT, a frequency is scanned once. Programmed conventionally, the same frequency is scanned multiple times--once for every combination of slot and talkgroup ID used.
 

mikewazowski

Forums Manager/Global DB Admin
Staff member
Joined
Jun 26, 2001
Messages
10,734
Location
Central Ontario
#22
troymail;298114[emoji646 said:
]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).

Winner!

Currently Proscan downloads each entry as a single OFT system which isn't ideal but it's trivial to cut and paste to make one OFT system.

Uniden could easily flag the same frequency with the same color code and convert those entries to OFT or respect the information in the database and give the user the choice whether they want to convert them to OFT systems. However, for some reason Uniden refuses to do this.

Keep in mind that as far as I know, no provider of commercial two way gear refers to these entries as trunked. They are entered as conventional channels. Same as Uniden's single channel P25 trunking. Those channels are entered in as conventional channels with conventional talkgroups.

This horse has been beaten to death enough already. Unless RR database policy changes to favor Uniden or Uniden's programmers figure out how to do it, it will never change.

I'm out.
 

DaveNF2G

Member
Premium Subscriber
Joined
Jan 23, 2001
Messages
9,126
Location
Rensselaer, NY
#23
Does anyone here actually have or use a DMR transceiver on amateur radio?

Each frequency must be programmed in one time for each talkgroup. That is how multiple talkgroups are handled. It is a kludge for a technology that was not designed for multiple TGs on "conventional" repeaters.
 
Joined
Jul 18, 2014
Messages
8,884
Location
PA
#24
Does anyone here actually have or use a DMR transceiver on amateur radio?

Each frequency must be programmed in one time for each talkgroup. That is how multiple talkgroups are handled. It is a kludge for a technology that was not designed for multiple TGs on "conventional" repeaters.
And current RR policy is expecting that kludge to be applied to all scanners, even ones that don't require it, despite the current existence of a system format in the database that allows not using the kludge if the scanner doesn't require it, without breaking compatibility with brands of scanners that still require the kludge. Very short-sighted IMO.
 
Status
Not open for further replies.
Top