Conventional DMR Imports from RRDB

So, it's been a while but I did a library import of some conventional businesses channels with Sentinel...

Decided to lockout ("Avoid") some channels on the 436 and when I do, in several cases, the same conversation pops up on another entry from the import...

I just looked and see that the imported entries do not setup properly on the 436 because they are importing as basic conventional channels (vs. any type of DMR) and totally ignore the slot information....

Maybe this has been raised before but why isn't this imported properly as DMR (sing the available information including slots)?

On a related note - I see that conventional NXDN is imported as basic conventional as well (i.e. as if analog) even thought the Unidens don't do NXDN--- why?

Uniden doesn't consider basic conventional the proper way to program conventional DMR users. They think each DMR user should be programmed as DMR One Frequency systems. As basic conventional the Uniden simply ignores slot and talkgroup. IMHO, I think we should be able to program DMR as basic conventional with slot and TGID if we choose to do so. I have found several users in my are that simply have one frequency, one TGID, one slot.

I guess since the NXDN is listed under conventional programming via RR, it just lumps those in with all other conventional analog frequencies? I never noticed that before.

It's as if they didn't put any effort into conventional at all...

troymail said:

It's as if they didn't put any effort into conventional at all...

Click to expand...

Yup, it's like having a community repeater with individual users each having their own ctcss tone but Uniden downloads every channel as carrier squelch.

It gets worse when you've got data on the frequency. A Uniden scanner will sit there and not scan. You've got to lock the channel out and make a one frequency trunk system.

Most of the public works department in my area use avl on the second timeslot. I've had to make multiple systems up so my scanner doesn't hang on their channels.

So much for these things being easier to use. A beginner will punch in his location, select the services he wants to listen to and hope none of the channels selected are dmr with any sort of data.

Also thought I was receiving a known conventional user on a frequency and they'd switched to CAP+ recently but it turned out the activity being received was a closer CAP+ system that is using the same frequency.

And yes, at tines, I noticed the radio got really quiet... turns out the radio was hanging on some imported frequency the was either data or a control/idle signal...

sibbley said:

Uniden doesn't consider basic conventional the proper way to program conventional DMR users. They think each DMR user should be programmed as DMR One Frequency systems.

Click to expand...

There is actually good logic behind that philosophy. If you dump a bunch of random DMR frequencies into one system, you have no guarantee that the same TGID/RID won't be used by multiple entities for different purposes. If you create a separate programmed system for each physical system, you can have separate definition for each use of TGID 100 or RID 100.

jonwienke said:

There is actually good logic behind that philosophy. If you dump a bunch of random DMR frequencies into one system, you have no guarantee that the same TGID/RID won't be used by multiple entities for different purposes. If you create a separate programmed system for each physical system, you can have separate definition for each use of TGID 100 or RID 100.

Click to expand...

Maybe for 'random' frequencies but when your import known DMR stuff from the RRDB with detailed attributes, it's kinda stupid.

jonwienke said:

There is actually good logic behind that philosophy. If you dump a bunch of random DMR frequencies into one system, you have no guarantee that the same TGID/RID won't be used by multiple entities for different purposes. If you create a separate programmed system for each physical system, you can have separate definition for each use of TGID 100 or RID 100.

Click to expand...

I'm not following you. You just can't dump a bunch of random frequencies into a Conventional system. Each channel has one frequency.

If Uniden had done things properly, a Conventional system would consist of a Department and Channels. Channels would consist of a Frequency (already there), timeslot, color code and group. This information is already in the database.

It wouldn't matter if two entities used the same group, timeslot or color code. They're differentiated by frequency.

MikeOxlong said:

I'm not following you. You just can't dump a bunch of random frequencies into a Conventional system. Each channel has one frequency.

If Uniden had done things properly, a Conventional system would consist of a Department and Channels. Channels would consist of a Frequency (already there), timeslot, color code and group.

Click to expand...

They shouldn't be programmed as a Conventional system. If users use both timeslots or more than one group, then each permutation would have to be programmed as a separate channel, even if the frequency is the same. That wastes scanning time because you're looking at the frequency for activity on TS1 TG1000 CC5, then move the next channel looking for activity on the same frequency on TS2 TG 1005 CC5, etc. It's much more efficient to scan a system programmed as One Frequency.

Programming each physical system as its own programmed system also allows the correct location coordinates and service radius to be programmed, rather then dumping a hodgepodge of stuff into a catchall department (e.g. the business entries for Franklin County PA) with catchall location coordinates and a much larger-than-necessary service radius (because the service radius has to cover everything in the catchall area rather than the actual service area of each business).

As an example, the Lincoln Way (Exit 16) Department has a service radius of 27.4 miles, even though the actual businesses in the Department have an actual service radius/receivable range of maybe 1/2-mile. Most of the businesses are using handhelds and simplex, not repeaters. The same is true of the Wayne Avenue (Exit 14) Department. The end result is that Location Control is getting borked because the scanner is scanning stuff it can't possibly pick up because of crappy database data. If each business was in its own System (for DMR/NXDN) or Department (for conventional freqs) then the location coordinates could be set to the actual location of the business, and the service radius could be set to something far more reasonable, like 1 mile or less, and the scanner would only try to scan the business when it had a reasonable chance of receiving it.

Sorry Jon but I'm going to disagree.

When I travel, I rely on the built in database to handle things for me. I don't want to have to create one frequency trunking systems for every conventional DMR system I might encounter. I also don't want to have to lock out frequencies because the second timeslot carries data and my scanner hangs on the channel because Uniden basically treats them as carrier squelch.

I could see how a scanner used in a home situation would benefit from setting up one frequency trunking systems but when traveling across hundreds of miles in unfamiliar territory, it sucks. I don't have time to pull over and create a system.

MikeOxlong said:

When I travel, I rely on the built in database to handle things for me. I don't want to have to create one frequency trunking systems for every conventional DMR system I might encounter

Click to expand...

That is exactly why those frequencies should be entered as one frequency trunked systems in the RR database in the first place, so that they import into Sentinel as such. The only time a DMR frequency should be entered in the database as a conventional frequency is if it only ever uses one combination of color code, timeslot and talkgroup ID (e.g. always CC5, TS2, and TGID100). If the frequency uses multiple permutations of timeslot and talkgroup ID (e.g. both timeslots are used, or multiple talkgroup IDs are used), then it should be entered as one frequency trunked, no exception.

That will prevent the scanner from hanging on data and control channels, and will make GPS scanning work significantly better, because the scanner is going to be trying to scan less stuff that is actually out of range.

jonwienke said:

That is exactly why those frequencies should be entered as one frequency trunked systems in the RR database in the first place, so that they import into Sentinel as such.

Click to expand...

So the way we enter in simple DMR conventional frequencies should be changed so we can overcome Uniden's software limitations?

Whistler doesn't seem to have a problem handling it. It respects the information entered into the database and treats multiple DMR users on the same frequency as separate entities.

If Whistler can do it, why can't Uniden?

MikeOxlong said:

If Whistler can do it, why can't Uniden?

Click to expand...

Like I was told many times over when One Frequency Systems scanned very slow, It's inefficient. If it only has one frequency, it's a One Frequency System.

IMHO, I still think it's a crock of bull.

MikeOxlong said:

So the way we enter in simple DMR conventional frequencies should be changed so we can overcome Uniden's software limitations?

Click to expand...

If multiple combinations of timeslot and/or talkgroup are being used, then it isn't a "simple conventional frequency", and it doesn't make sense to enter it as such. It makes more sense to enter it as one frequency trunked. This is especially true if the frequency carries control channel data for an actual trunked system. If that is the case, it should never be programmed as conventional.

jonwienke said:

If multiple combinations of timeslot and/or talkgroup are being used, then it isn't a "simple conventional frequency", and it doesn't make sense to enter it as such. It makes more sense to enter it as one frequency trunked. This is especially true if the frequency carries control channel data for an actual trunked system. If that is the case, it should never be programmed as conventional.

Click to expand...

Control channel data? That would be a trunked system and entered as such. Not sure why you're bringing that up? We're talking about Uniden's inability to handle conventional DMR database entries like Whistler does.

It's still a conventional frequency and should be entered as such. It is not a trunked system. Why Uniden thinks it should be entered as a trunked system is strange.

jonwienke said:

If multiple combinations of timeslot and/or talkgroup are being used, then it isn't a "simple conventional frequency", and it doesn't make sense to enter it as such. It makes more sense to enter it as one frequency trunked. This is especially true if the frequency carries control channel data for an actual trunked system. If that is the case, it should never be programmed as conventional.

Click to expand...

So then... why doesn't Uniden make it so during their import of the data?

MikeOxlong said:

We're talking about Uniden's inability to handle conventional DMR database entries like Whistler does.

It's still a conventional frequency and should be entered as such. It is not a trunked system. Why Uniden thinks it should be entered as a trunked system is strange.

Click to expand...

Users should call Uniden, request them to change the way they handle the DMR stuff in the Uniden scanners.

https://www.uniden.com/about-uniden

MtnBiker2005 said:

Users should call Uniden, request them to change the way they handle the DMR stuff in the Uniden scanners.

https://www.uniden.com/about-uniden

Click to expand...

I've asked about this before I wish they can have something like this on uniden. This screen shot is the whistler software.

troymail said:

So then... why doesn't Uniden make it so during their import of the data?

Click to expand...

Yup, it would make much more sense to have these imported as One Frequency trunk systems rather than the conventional type that the Unidens don't support.

This very discussion is also a BIG reason I don't even use the database on the SD card. I've been simply creating my own OFT systems based on what I find through RR, the FCC, or through my own band searches. Since Uniden addressed the issues with OFT, they do work quite well.