Help me help you

[JoeBearcat]

Once engineering has come up with a "solution" for the hum, might I suggest having a select amount of users send in their scanners to confirm this works before this modification is accepted? I have two...one of the first and a later model. My "hum" doesn't affect me like others that listen in a quiet listening environment or not as much activity as I have. If I had a repair needed, I would mention it while sending it in, but that hasn't been the case. Free shipping label perhaps?

Several units have already been evaluated. Are there any examples where the varnish removal has *not* cured the issue?

 

[werinshades]

Several units have already been evaluated. Are there any examples where the varnish removal has *not* cured the issue?

You've mentioned a couple different methods used, is that the "final" answer...lol! If someone sends it in to Uniden for the hum, is that the authorized repair being performed? I prefer any modification to be performed by the company itself, in the event something is damaged etc.

 

[JoeBearcat]

You've mentioned a couple different methods used, is that the "final" answer...lol! If someone sends it in to Uniden for the hum, is that the authorized repair being performed? I prefer any modification to be performed by the company itself, in the event something is damaged etc.

The varnish removal (more accurately non-application in the screw areas) is the solution I proposed for manufacturing. Repair is evaluating that compared to their existing fix. What they decide will be up to them.

 

[werinshades]

The varnish removal (more accurately non-application in the screw areas) is the solution I proposed for manufacturing. Repair is evaluating that compared to their existing fix. What they decide will be up to them.

I can't answer the question as to whether any "varnish removal" procedures were unsuccessful. What is the disadvantages that have been discovered with the existing fix vs varnish removal?

 

[CanesFan95]

What this seems to come down to is: You can trunk or you can decode. Only trunking will give access to the trunking features such as TGs and slots. That is why OFT was added. If the user uses analog and digital, you may have to program those as two separate systems if you want to use the trunking features on the digital channels.

Your posts are really appreciated. I'm not sure slots & TGs are considered a "trunking" feature though. Those are attributes that are programmed as a part of a conventional DMR frequency, just like on an XPR radio. For actual DMR trunking like Capacity Plus, you actually don't specify any slot # because it trunks around.

 

[JoeBearcat]

I can't answer the question as to whether any "varnish removal" procedures were unsuccessful. What is the disadvantages that have been discovered with the existing fix vs varnish removal?

If you mean the metal tab fix, the issue sometimes returned. The varnish fix is more reliable. There was also a report that the tab put pressure on the display which was not a good thing. While that was a secondary concern, since there is a better fix that should be used. It also will likely be lower cost in the long run (no cost of the tab).

 

[CanesFan95]

Not true. Their are systems that utilize both slots, sometimes with different talkgroups etc. Talkgroup 10 might be using CC-7, slot 1 and be referred to as Channel 1. Talkgroup 20, might be using CC-7, slot-2 and be referred to as Channel 2. Just an example as how this feature is a benefit.

^ This is exactly my situation. Southwest Airlines uses a separate TG on each slot. They're busy and sometimes both slots are active. So if the BCD996P2 doesn't let you tell it the slot #, you'll hear mixed comms from both slots.

 

[JoeBearcat]

Your posts are really appreciated. I'm not sure slots & TGs are considered a "trunking" feature though. Those are attributes that are programmed as a part of a conventional DMR frequency, just like on an XPR radio. For actual DMR trunking like Capacity Plus, you actually don't specify any slot # because it trunks around.

They are trunking features in that there are no provisions for conventional frequencies to enter things like TGs and slots.

We could add that capability. Perhaps we could call it "One Frequency Trunk"?

The color code is a conventional feature and can be entered for conventional channels.

I'm sure you can appreciate that TGs cannot be treated like CTCSS/CDCSS/NAC/CC/RAN where there is one entry per channel. If we were to change CC to TG, someone would complain that we don't distinguish between two users using the same TG but different Color Codes.

 

[werinshades]

If you mean the metal tab fix, the issue sometimes returned. The varnish fix is more reliable. There was also a report that the tab put pressure on the display which was not a good thing. While that was a secondary concern, since there is a better fix that should be used. It also will likely be lower cost in the long run (no cost of the tab).

Ok..so it's the "metal tab" fix we've been performing ourselves. Yes...that was a temporary resolution that I performed on my original SDS 200. The second one I purchased in Dec. 2019 is quiet as a church mouse.

I don't want to open the flood gates for a massive repair campaign, but it appears to be heading down this path. Hopefully anyone that has sent one in for repair has had this done for them.

 

[JoeBearcat]

^ This is exactly my situation. Southwest Airlines uses a separate TG on each slot. They're busy and sometimes both slots are active. So if the BCD996P2 doesn't let you tell it the slot #, you'll hear mixed comms from both slots.

O F T

 

[werinshades]

^ This is exactly my situation. Southwest Airlines uses a separate TG on each slot. They're busy and sometimes both slots are active. So if the BCD996P2 doesn't let you tell it the slot #, you'll hear mixed comms from both slots.

Many Southwest systems are Cap+ which would show the fluctuating Slot numbers, but I know at Chicago-Midway, we have a OFT used as Channel 7 in the radios. This is used at the T-Point (Transfer Point/Baggage Alley) because they were having issues being underneath a concrete block of the airport.

They will be flying out of Chicago-O'Hare starting tomorrow, and are licensed to use an OFT frequency so we'll see what comes up.

 

[JoeBearcat]

Ok..so it's the "metal tab" fix we've been performing ourselves. Yes...that was a temporary resolution that I performed on my original SDS 200. The second one I purchased in Dec. 2019 is quiet as a church mouse.

I don't want to open the flood gates for a massive repair campaign, but it appears to be heading down this path. Hopefully anyone that has sent one in for repair has had this done for them.

A campaign would probably only be authorized if this is an issue on most units (like the display issue of the x36). So far , it seems it is not, and actually varies to degree on units that experience it.

I have to wonder if anyone has tried this: Loosen the screws and shift the board to one side so the edges of the screws make better contact with the feedthroughs. This is just a theory, and I have not tested it since I do not have any units that have these symptoms. I would not call it a fix, but it would provide valuable intel and might explain why not all units have the issue.

 

[jonwienke]

You seem to have trouble understanding the concept of burning a quick key for every single individual DMR frequency is cumbersome and basically rediculous. Outside of ham radio, most conventional DMR frequencies will only have 1 TGID active on each slot. For ham stuff, I would just leave it open like promiscuous mode, but would still wanna limit it to just one slot at a time. So even if you opted to program a DMR frequency twice and scan it twice, that's not really hat bad. Much better than having to turn off / on hundreds of quick keys.

It is that bad, because programming every frequency twice doubles the time it takes to scan them. And if you're talking enough frequencies to run out of quick keys, doubling scan time is not trivial.

And as I said before, if you put 1-frequency systems in their own favorite list(s), it is in fact possible to turn them all on and off with with a single quick key, and your claims to the contrary are utter nonsense.

^ This is exactly my situation. Southwest Airlines uses a separate TG on each slot. They're busy and sometimes both slots are active. So if the BCD996P2 doesn't let you tell it the slot #, you'll hear mixed comms from both slots.

It does allow you to program a slot, if you program the system as 1-frequency. You just choose not to do that.

No, respecting the color code, group and slot information in the database is how you keep separate conversations and DMR data from getting mixed up. Instead, Uniden forces everyone to either live with the mess or you create OFT systems for all your conventional DMR entries.

...

I understand why Uniden did it but they should have respected the information in the database and allowed those that want to create OFT systems the option to do so or at least build in the functionality in Sentinel to convert conventional DMR frequencies to OFT. That functionality exists in ProScan so it could have easily been integrated into Sentinel.

You make a valid point about auto converting from multiple duplicate conventional frequency entries to a 1-frequency system. But it's still at least twice as fast to scan a 1-frequency system compared to the equivalent list of duplicated conventional frequencies.

 

[werinshades]

A campaign would probably only be authorized if this is an issue on most units (like the display issue of the x36). So far , it seems it is not, and actually varies to degree on units that experience it.

Might this be the isolated to the where the units were manufactured? As you know, we see alot of posts and not all affected units are new vs. old.

 

[mikewazowski]

They are trunking features in that there are no provisions for conventional frequencies to enter things like TGs and slots.

Only in the eyes of Uniden. Motorola CPS will allow me to program a conventional channel with a group, timeslot and color code. Even a Whistler scanner can do this. The RadioReference database also treats these as conventional channels.

If Uniden is going to force users to use OFT to scan conventional channels, then at least include the capability to convert conventional DMR channels to OFT systems in Sentinel. Once again, ProScan can do it so why not Sentinel? Perhaps your software engineers can talk to Bob at ProScan and do whatever it takes to include his conversion program into Sentinel. I guess that would be my ask for this thread.

You make a valid point about auto converting from multiple duplicate conventional frequency entries to a 1-frequency system. But it's still at least twice as fast to scan a 1-frequency system compared to the equivalent list of duplicated conventional frequencies.

I agree that OFT is the way to go.

However, keep in mind that there are a ton of systems out there using the second timeslot as a data channel. This second timeslot information isn't typically included in the database so users only see one entry. If that second timeslot carries AVL data (which typically is firing off every few seconds for a busy system), then a users scanner hangs on the channel. Sure, you can create an OFT system for it but if I'm travelling, I don't want to have to create OFT systems for every DMR channel in the full database just in case I run into an AVL system.

 

[lu81fitter]

Not true. Their are systems that utilize both slots, sometimes with different talkgroups etc. Talkgroup 10 might be using CC-7, slot 1 and be referred to as Channel 1. Talkgroup 20, might be using CC-7, slot-2 and be referred to as Channel 2. Just an example as how this feature is a benefit.

I have a group I listen to in my area that uses a single frequency in DMR mode. They are the only group that uses that frequency. My 996P2 has the DMR upgrade, and I can program the freq in conventional analog and it comes thru just fine. Or, I can program it with the slot and color code. That works as well. As JB said above, it comes down to "decoding" or using "trunking". If no one else is on that freq, it performs just fine. If it is used by multiple entities, then using a trunked format would be the recommended programing style.

 

[werinshades]

I have a group I listen to in my area that uses a single frequency in DMR mode. They are the only group that uses that frequency. My 996P2 has the DMR upgrade, and I can program the freq in conventional analog and it comes thru just fine. Or, I can program it with the slot and color code. That works as well. As JB said above, it comes down to "decoding" or using "trunking". If no one else is on that freq, it performs just fine. If it is used by multiple entities, then using a trunked format would be the recommended programing style.

You can program any DMR frequency as conventional, however you're limited as to what you can program if you encounter other talkgroups/slots on that frequency. Other users have programmed Cap+ systems as conventional due to confusion is how to program these systems, then don't understand whey the scanner is "hanging up" while scanning. With the current software, the optimum programming for these systems is OFT. While it might work to program as conventional for some, if you encounter a "rest channel" and the scanner "hangs up", some users won't understand why.

Another advantage to OFT programming is you can view Radio ID's, which might assist in identifying unknown users. Run it in ID Search so all talkgroups and slots could be properly identified.

 

[sallen07]

You seem to have trouble understanding the concept of burning a quick key for every single individual DMR frequency is cumbersome and basically rediculous.

Wait. Which scanner are you using? BCD996P2?

I think this is where the disconnect is. There is no need to "burn a quick key" for each one-frequency trunk system. It's not a one-to-one relationship. You can create 100 different one-frequency trunk systems and assign them all to ONE quick key. Yes, it creates a *system* for each one, but that's not the same as a quick key. The system is where you can list slot and TG(s).

I sometimes monitor local ham repeaters on a 996P2. About 10 analog repeaters and 3 DMR repeaters, each of which is programmed as a single-frequency trunk. ONE quick key for all of them.

Similar situation with the local highway departments, many of which have converted from analog to DMR. I have probably 7 or 8 different towns programmed in, half analog, half one-frequency trunk. ONE quick key.

There is no more need to give each one-frequency trunk its own quick key as there is with a conventional frequency. On a 996P2 you assign system(s) to a quick key, you don't assign a quick key to A system. It's not one-to-one. A quick key can have one (or zero) systems assigned to it, or it can have 10 or 100.

It's fine to debate whether or not Uniden implemented this "the right way", but this IS the way they implemented it, and if you want "conventional" DMR to work correctly you have to use one-frequency trunk. If you don't then you have the problems you listed: scanner stops on DMR channel with no voice traffic, can't program slot or TG, etc.

 

[W5RGP]

One definitely. Those are (I think) the only two models that will not get a hardware update. There will be at least one firmware update to correct a minor bug and hopefully more later this year.

how about an option to use decimal instead of hex for sys id or just hard code decimal instead like we had on the x36 models

 

[JoeBearcat]

how about an option to use decimal instead of hex for sys id or just hard code decimal instead like we had on the x36 models

That (user option) is already on the feature request list.