Help me help you

[JoeBearcat]

Hey Joe, your "slip" is showing! Is someone named Jon joining to enterprise? Maybe I missed a post or two. Well having one more tech on board certainly can't hurt matters, as long as those hardware updates are being paid for by Uniden of course, and not the consumer. And as long as they do not void the consumer warranty.

Additionally, as long as he can keep up with the amount of stuff that is likely to come his way from scanners currently under warranty from past, present and future inventories which are not part of the newest "improved" batches expected to coming off production at some point.

What may be needed might be a "Jon" type person heading up a centralized team of trained specialists to handle just those matters which seem to come under his purview.

And while that we be a great step forward, folks are still going to be leery about making a $700 USD purchase at this time knowing that there is a chance that one's investment is going to take a month or two to come to the proper fruition while awaiting said repairs/modifications.

But of course, this is all hypothesis at this point. Or is it?

Uniden has stated (and I posted in another thread) that warranty will be on a case-by-case basis. I believe there are many people who would be willing to do the mod in a quality workman like manner - perhaps at a lower cost then the repair shop. Now I cannot officially endorse Jon, but I have heard he does quality work and I've seen pics of his work. It's not perfect (sorry Jon) but it is very high quality. And yes, I have seen rework that is indistinguishable from factory. That, BTW, is from someone who used to do that 8 hours/day 5 days/week.

No, Jon is not joining the team (as far as I know), but I bet he could perform many of the involved mods based on the mods he is already performing.

Keep in mind the vast majority of scanners have no issues. All we are doing is driving down the percentages of those that will develop them. There will always be a certain percentage of units that may develop an issue of some type. QC can only do so much, and part failures are always possible (and if any scanner manufacturer tells you otherwise, run).

 

[jonwienke]

Rhetorical question: How many people would pay $100 more for a 996-type scanner that has a built-in GPS that they will never use in a stationary installation?

GPS wouldn't add anywhere near that much. Look at the price difference between the TYT MD-380 variants with and without GPS. Retail price difference is more like $20, which is not a deal-breaker, especially for the SDS lineup..

BTW, my GPS module vendor is interested in having a conversation with you on the subject...

 

[CanesFan95]

I tried to parse your post, but the bullet points won't parse well.

How is your scanner oriented? The bottom-firing speaker will be affected by surrounding materials, and will have a more bassy quality since it's larger. Some people like more tinny audio. For that you can use a smaller external speaker.

Good point on the data channels. Added to the feature request list.

One-frequency Trunk.

The rest channel changes. If it stayed on one it would miss calls.

Again, switching is a good idea. Another feature request listing.

What would you get rid of on the display? Or would you just make lines 2 and 3 smaller?

I do use an external speaker. Yes, the rest channel changes. The rest channel is what the radio needs to tune to know when to go where to receive the next voice call. Therefore, the scanner needs to follow the rest channel when it changes. For the display, it's not to get rid of anything. It's to use up the available blank pixels to display more info, like for example here, there's room to the right of the TGID to show the RF frequency:

Or here on this DMR frequency, if you push the "NFM" and the CC all the way to the left, you could fit the slot # & TGID or LCN (CC not visible here because it blinks and was missed in the photo - would be nicer if it didn't blink):

 

[CanesFan95]

No. Programming as one frequency is always more efficient than programming conventional. If you have 3 talkgroups on a 2 frequency system, you have to program 12 conventional channels (3 talkgroups x 2 frequencies x 2 slots) to cover all of the permutations, each of which has to be scanned separately. Programming as 1-frequency means each frequency gets checked only once before moving on, and the system gets scanned 6x faster than the conventional channels. It's nuts not to use 1-frequency.

And you can include slot in a 1-frequency talkgroup entry...

But there is no 2-frequency "system". It's not a "system", just 1 conventional frequency. All I'm saying it would be nice when you program a conventional DMR frequency that you'd have a couple more columns to tell it the slot & TG, like the Whistler scanners.

 

[lu81fitter]

But there is no 2-frequency "system". It's not a "system", just 1 conventional frequency. All I'm saying it would be nice when you program a conventional DMR frequency that you'd have a couple more columns to tell it the slot & TG, like the Whistler scanners.

What program are you using to program your scanner? In Proscan, you can program a "DMR one-freq trunk". When you get to part where you enter the talk group ID's, it gives you an option to enter a TDMA slot #. At the system level, you can set it to "ID search" or "ID scan". When entering "Site frequencies", you can enter a color code, or have it search for one.

 

[rgchristy]

I'll second that....

But there is no 2-frequency "system". It's not a "system", just 1 conventional frequency. All I'm saying it would be nice when you program a conventional DMR frequency that you'd have a couple more columns to tell it the slot & TG, like the Whistler scanners.

 

[rgchristy]

Doesn't it require an additional system or layer? You can't just add it to an existing system or department? For example, I have a Department for our local school district. It includes all of the analog and DMR frequencies for the district, with the exception of the buses, because another user on the frequency uses the same color code. It would be easier to be able to just enter the frequency in the existing department and select slot (1, 2 or any), CC (# or any) and TGID (# or any). I'm no way an expert on this, so I could be wrong.

What program are you using to program your scanner? In Proscan, you can program a "DMR one-freq trunk". When you get to part where you enter the talk group ID's, it gives you an option to enter a TDMA slot #. At the system level, you can set it to "ID search" or "ID scan". When entering "Site frequencies", you can enter a color code, or have it search for one.

 

[Jimru]

I'd say one of the most common unresolved thread topics have to do with Simulcast Distortion - what it is - what issues it causes - and how the SDS scanners overcome it.

It probably comes up several threads per week. I'm sure you've seen it. Good luck!

There is already a RR Wiki page devoted to that here: Simulcast Distortion - The RadioReference Wiki

 

[jonwienke]

But there is no 2-frequency "system". It's not a "system", just 1 conventional frequency. All I'm saying it would be nice when you program a conventional DMR frequency that you'd have a couple more columns to tell it the slot & TG, like the Whistler scanners.

Actually there are plenty of systems that use two or more frequencies, and it is always more efficient to program them as 1-frequency trunked. You only have to program talkgroups once per system, rather than once per frequency.

Adding talkgroup and slot info to a conventional frequency is completely useless. If the talkgroup/slot never changes for a conventional frequency, then entering that info into the channel programming is a pointless and redundant waste of time. But if they do change, then programming as 1-frequency trunked means you'll scan n times faster as 1-frequency vs conventional, where n is the number of talkgroup/slot permutations for the system.

There is no situation where programming a talkgroup or slot for a conventional channel is wise or beneficial. It's either pointless and redundant because the talkgroup/slot never change, or else you're manifestly better off programming as 1-frequency trunked because they do. There is no third option.

 

[buddrousa]

OK. Throwing this out there for a request. Memory format such as the 996 or 15X scanners (No SD card), same user interface as those models (buttons, keys, etc.), only use the SDR of the SDS100/200 models. I have 2 15X's, a 996P2, and a 325P2. They are great radios. The 15X and 996 line are rock solid and are good performers for their intended purpose. Adding the SDR to these would be... well, Wonderful!

As posted by UPMan years ago. You would still have memory problems and the scanner would have to be sent back to Uniden for repair and not fixed by the owner.

 

[cg]

Can the dynamic memory be expanded at the talkgroup levels on the existing radios via firmware?
The issue I am running into with the 996P2 is the limit of 500 talkgroups per system. The local system has ISSI and allows other trunked system users onto the Statewide system. They are given a temporary talkgroup that changes. So the FD radio traffic today might be encrypted PD traffic tomorrow. Because they change and are unable to be accurately labeled, I would prefer to keep them off. However, they appear in a range of 200 groups so between those and the regular groups, I am over the limit. Right now my work around is to edit a ProScan file and put them in as locked out unprogrammed talkgroups. But often they don't get read and reprogrammed after editing channels.

chris

 

[doctordialtone]

They are given a temporary talkgroup that changes.

Chris,

You'll notice that those 65XXX groups are always ending in an even number.

I put them all in a group called "Lockouts" and permanently lock them out - and haven't heard one in months.

Just a thought...

 

[cg]

But there are currently >614 groups on the system so even with 100 ISSI, you are locked into using ID SCAN (I want to know new groups so always on ID SEARCH). I would like to be able to enter every group.
I am still only using 19% of the scanners memory so I was hoping some of these limits can be stretched.

 

[JimD56]

I have no use for GPS, DMR, NXDN, or ProVoice. Don't make me pay for it by building it into a unit and jacking the price.

 

[buddrousa]

It does not cost you anymore until it is turned on.
Look at the 996p2 325p2 536 436 sds100 sds200.

 

[CanesFan95]

Actually there are plenty of systems that use two or more frequencies, and it is always more efficient to program them as 1-frequency trunked. You only have to program talkgroups once per system, rather than once per frequency.

Adding talkgroup and slot info to a conventional frequency is completely useless. If the talkgroup/slot never changes for a conventional frequency, then entering that info into the channel programming is a pointless and redundant waste of time. But if they do change, then programming as 1-frequency trunked means you'll scan n times faster as 1-frequency vs conventional, where n is the number of talkgroup/slot permutations for the system.

There is no situation where programming a talkgroup or slot for a conventional channel is wise or beneficial. It's either pointless and redundant because the talkgroup/slot never change, or else you're manifestly better off programming as 1-frequency trunked because they do. There is no third option.

Program 2 or more frequencies as 1-frequency trunked? LOL. Adding TG & slot info is not useless. If you're listening to a conventional DMR frequency and both slots are active, you'll hear a mixture of 2 different conversations, not what I want. And if either slot could have different TGs (rare in commercial radio, frequent on the ham bands), then you'll hear different mixed up stuff. Not being able to tell the scanner what TG & slot basically messes up your monitoring. So there is absolutely a benefit to being able to program the slot and TGID. I even have an XPR7550e and that's how you do it. Even an actual real commercial radio lets you tell it what slot, TG, & color code. Nothing pointless about that.

And besides, it would be absurd to program each and every one of your conventional DMR frequencies as it's own whole separate trunking system, cause that'll eat up all your quick keys very quickly. It also makes it difficult and awkward to just simply scan a list of conventional DMR frequencies. I don't wanna have to sit there and press 100+ quick keys everytime I wanna scan DMR conventional. And then trying to remember which is one is which. Absurd.

 

[buddrousa]

The completion is no better on DMR by just scanning VOICE CHANNELS
If you have that much then you are missing too much with just 1 scanner

 

[jonwienke]

Program 2 or more frequencies as 1-frequency trunked? LOL. Adding TG & slot info is not useless. If you're listening to a conventional DMR frequency and both slots are active, you'll hear a mixture of 2 different conversations, not what I want. And if either slot could have different TGs (rare in commercial radio, frequent on the ham bands), then you'll hear different mixed up stuff. Not being able to tell the scanner what TG & slot basically messes up your monitoring. So there is absolutely a benefit to being able to program the slot and TGID. I even have an XPR7550e and that's how you do it. Even an actual real commercial radio lets you tell it what slot, TG, & color code. Nothing pointless about that.

1-frequency is how you program slots and talkgroups to keep separate conversations from getting mixed up. It's a more efficient way to scan systems with multiple talkgroups than programming multiple conventional channels. If you're too stubborn to use it, that's your problem.

And your quick key argument is ridiculous. You can't assign quick keys to individual conventional channels. But if you have multiple talkgroups in a 1-frequency system, you can put each one in a separate department, and assign each department a quick key. Your system quick keys used will be less than the total number of channels keyed.

 

[CanesFan95]

Here's a thread I posted a while back with photos and videos showing how the BCD996P2 misses Cap+ voice calls compared to DSD+ side-by-side:

BCD996P2: - BCD996P2 Not Stopping On Capacity Plus Talk Groups

 

[CanesFan95]

1-frequency is how you program slots and talkgroups to keep separate conversations from getting mixed up. It's a more efficient way to scan systems with multiple talkgroups than programming multiple conventional channels. If you're too stubborn to use it, that's your problem.

And your quick key argument is ridiculous. You can't assign quick keys to individual conventional channels. But if you have multiple talkgroups in a 1-frequency system, you can put each one in a separate department, and assign each department a quick key. Your system quick keys used will be less than the total number of channels keyed.

Your sense of logic is flawed (and why do you have to have such a negative attitude on here calling me "stubborn" and "my problem"). Yes, I'm fully aware you can't assign assign quick keys to a conventional frequency. Never said that. I'm saying that if you have to go and program each and every single conventional DMR frequency as a "trunking system" (even though it's conventional, not trunking ), then you're having to use up a quick key number which is ludicrous if you have like 100 DMR frequencies in your town.

So I'm supposed to sit there and turn on/off 100 quick keys to scan everything, as opposed to one simple list?