Help me help you

[bravo14]

@JoeBearcat On Sentinel One Freq Trunk the P-Ch is greyed out. Is this in the works to ungrey? I have made many OFT on certain area(s) & counties around me they use more than 1 TG on a same freq. Another question is Record option being tweaked were we only can record certain TG/Channels not every one? Thanks.

 

[jonwienke]

@JoeBearcat On Sentinel One Freq Trunk the P-Ch is greyed out. Is this in the works to ungrey? I have made many OFT on certain area(s) & counties around me they use more than 1 TG on a same freq. Another question is Record option being tweaked were we only can record certain TG/Channels not every one? Thanks.

View attachment 97639

Priority in a trunked system doesn't work the same way it does in a conventional/non-trunked system. The scanner doesn't ever scan talkgroups, it scans site frequencies. On a trunked system the scanner cannot merely look for a carrier on a site frequency, it must dwell on the frequency for 1-2 seconds to parse control channel data to figure out what if any calls are active, and which voice channel(s) they are using, as opposed to a carrier check, which only takes about 1/80 of a second. So doing a conventional style priority scan on a trunked system would take much longer--too long to be useful.

Instead, P25 systems announce new calls during existing calls, and if a new call is on a talkgroup tagged as priority, the scanner can drop the existing call and jump to the new one. OFT systems don't have that functionality, so they don't have either type of priority as an option. It's just the nature of the beast.

 

[bravo14]

Priority in a trunked system doesn't work the same way it does in a conventional/non-trunked system. The scanner doesn't ever scan talkgroups, it scans site frequencies. On a trunked system the scanner cannot merely look for a carrier on a site frequency, it must dwell on the frequency for 1-2 seconds to parse control channel data to figure out what if any calls are active, and which voice channel(s) they are using, as opposed to a carrier check, which only takes about 1/80 of a second. So doing a conventional style priority scan on a trunked system would take much longer--too long to be useful.

Instead, P25 systems announce new calls during existing calls, and if a new call is on a talkgroup tagged as priority, the scanner can drop the existing call and jump to the new one. OFT systems don't have that functionality, so they don't have either type of priority as an option. It's just the nature of the beast.

Dang thanks for the info.

 

[GTR8000]

Instead, P25 systems announce new calls during existing calls, and if a new call is on a talkgroup tagged as priority, the scanner can drop the existing call and jump to the new one.

The caveat being that the talkgroup(s) must be provisioned as priority enabled in the trunked system controller, otherwise there is no guarantee that the grants will be broadcast over the traffic channel low speed data. And yes, there are P25 systems out there that do not have some/all talkgroups provisioned as priority enabled, so no matter how you set the scanner up, it may never revert to a talkgroup you have flagged as priority in the scanner's programming. Also, per my earlier post, I'm 99% certain that the x36HP and SDS series are not properly decoding/acting upon TDMA traffic channel low speed data as pertains to priority talkgroup grants. I will be testing further tonight to verify, so hopefully Uniden can fix that longstanding bug.

 

[pro106import]

@JoeBearcat ,
Regarding the SDS100/200, I really wish the squelch preset settings were either modified in the next firmware update or their values made user definable. Right now, we have setting 0 and 1 which are preset for open squelch. And when you go to 2, it closes the squelch, but set way to tight for my liking. Then when you go anywhere above 5, they are pretty much wasted settings. Since there is no analog pot like the Whistlers have, these preset values need to be looked at and fixed. I miss a lot of weaker signal transmissions when set at 2. By the way, I have owned several BCD396XT's for years and they have the same problem. But I just had to live with it. And it would be great if the squelch settings could be defined by channel or system at least, instead of globally as they are now.
Bob

 

[jonwienke]

@JoeBearcat ,
Regarding the SDS100/200, I really wish the squelch preset settings were either modified in the next firmware update or their values made user definable. Right now, we have setting 0 and 1 which are preset for open squelch. And when you go to 2, it closes the squelch, but set way to tight for my liking. Then when you go anywhere above 5, they are pretty much wasted settings. Since there is no analog pot like the Whistlers have, these preset values need to be looked at and fixed. I miss a lot of weaker signal transmissions when set at 2. By the way, I have owned several BCD396XT's for years and they have the same problem. But I just had to live with it. And it would be great if the squelch settings could be defined by channel or system at least, instead of globally as they are now.
Bob

I concur with this. Setting 4 is too tight to be useful in most cases on the x36 and SDS models; I rarely even use 3. If setting 15 was rescaled down to the current setting 5, and lower settings rescaled proportionately, squelch overall would be more useful, instead of most of the settings being far too tight to be of any practical use.

 

[SteveSimpkin]

Was wondering if TETRA is in the works?
+++

JoeBearcat wrote:
“Not at this time. The focus for the immediate future will be bug fixes. Given that TETRA was never a spec of the original design, it may not be approved for inclusion. Regardless, it will be in my wish list. My latest info is that only a few such systems exist in the USA near NJ.”

Help me help you

This will be added to the list, but at a (slightly) lower priority than some other issues since it involves more intense research and debugging. Would you be willing to help debug this issue? Absolutely. First thing I'll do is verify that the issue still exists, since it's been a while and I...

forums.radioreference.com

 

[baayers]

Hello Joe and welcome. It is nice to have contact again with those who make the scanners a reality.

Prior to UPMans passing there was discussion about extending the maximum charge time for the SDS100. If you run the scanner all the way down and then plug it in to charge and you use the charge while scanning option the timer kicks the charge cycle off about an hour to soon resulting in a flashing red light. At that point you have to unplug and replug to finish charging. This is with the supplied cable and wall charger. This issue was discussed about 18 months ago so I’m hoping this makes the list of things that can be fixed in the near future.

 

[MattSR]

Hi Joe,

One more thing I would like to add as well, is that the Australian market USDS scanner effectively is abandoned when it comes to firmware updates and bugfixes.

The current firmware version for the USDS100 is 1.10.01, which I believe is several versions behind the US models. Is it possible to get these models updated to the latest firmware? From a softawre engineering point of view, surely the effort in creating an additional build artefact for these models would be minimal, given that Uniden already have the build process/pipeline already in place?

https://uniden.com.au/wp-content/uploads/USDS100_Firmware-Update_MainV1.10.01-and-SubV1.02.01.zip

Cheers,
Matt

 

[bravo14]

@JoeBearcat On the sds100 & 200 I'm using the latest FW and still having issues with on replay or when recorded RID. This happens on Digital systems. Example say RID 10300 is Dispatch Console and RID 10334 is Tanker 4 Portable. When Tanker 4 10334 Keys up it shows up 10300 Disp and when disp 10300 says 10-4 on Tanker 4 Transmission. When not recording or replay it does normal. This has been happening for 2 years.

 

[jfr454]

SDS scanners have an issue tracking Hytera Type III DMR systems. I believe that this could be corrected with a modification to the firmware.

 

[JoeBearcat]

I think the most disappointing issue is that, in regards to the cold solder joint issue, this still continues to happen on at least some of the newer production units. Also, far too many of the SDS100's sent in to repair the J401 defect are coming back not repaired, or else they fail again within an unacceptably short period of time. It appears that the repair techs are only fixing what jumps out & slaps them upside the head, and leaving other problem connections untouched.

This issue has been brought up internally and action is being taken.

 

[buddrousa]

My 3 SDSx00's track a Hytera 3 DMR system just fine you have to setup the LCN correctly.

 

[JoeBearcat]

On NXDN systems that produce an Alias ID, maybe add a "Auto Store" feature that is user selectable (on or off) instead of going through the process of saving them..pressing Enter, Save Unit ID".

Please help me understand the benefit of saving a tag that is sent over the air. It seems to me (and I can be convinced otherwise) that if the tag is sent over the air, there is no need to save it.

Also, if the tags are auto-saved (or manually saved - or previously programmed) and the 'sent tag' is different, should the unit use the saved tag or the sent tag?

I suppose this issue deserves its own thread. Maybe an admin could do that?

 

[JoeBearcat]

The dimming screen on the 536 is actually still coming up and Uniden is no longer fixing them for free but charging for them.

This repair campaign had been ended because "the number of units received had dropped to a level that made the program no longer viable". I specifically asked management how to address the ending and this was the answer. I will not comment on the merits of that decision or my personal feelings.

It was a campaign that had lasted 7 years, or so I am told by others. I recall maybe 5 years. Either way it was a long time. The issue was fixed in production before the campaign started from my recollection.

This may not be a popular post, but please do not shoot the messenger.

 

[JoeBearcat]

Welcome @JoeBearcat glad to have you as a resource on here!

Three items (I know I'm nitpicking...)

1. The TWiki Page for the DMR upgrade is in need of a refresh... <snip>
   
   
2. Can the Discovery mode be changed to allow Durations of longer than 600 seconds (or even no limit)? <snip>
   
   
3. In Sentinel, would it be possible to have the software verify the correct profile is set for the correct device and issue a warning if its not? <snip>

1. The TWIKI is in the process of being reviewed and updated. I have been working on that since Friday. In many cases I am waiting on info from engineering. In others awaiting management approval (I took the 3-step BC_VUP process and made it 17 steps in total with pics across two pages - one for install and one for use).

2. I will add that to the feature request list.

3. I will add that to the feature request list as well. (check/warning+over-ride option)

To clarify, is it the profile you want validated or the setting under TOOLS/TARGET MODEL?

 

[JoeBearcat]

One really annoying problem when using the database: the Delay setting on the channel is hardcoded to 2 seconds and there is no way to adjust it without making a favorite list. 2 seconds is too short, in most cases the scanner resumes scanning in the middle of a conversation because someone is looking something up or checking their notes, etc. 5 seconds is a much more useful default, a better balance between holding on dead air at the end of a conversation and missing traffic because scanning resumed prematurely. You can change Delay in a favorite list, but it's a real PITA on large trunked systems with 1000+ talkgroups, even with ProScan's search and replace feature--something Sentinel completely lacks.
<snip>

Agreed on the global setting. Added that to the feature request list (and I will endorse that for future models even if it does not make the existing models).

For changing the delay on large groups of TGs/Channels: Change the first one. Copy that cell. Highlight all you want to change (standard windows feature using select/shift key+select or highlight and drag). Paste.

 

[JoeBearcat]

I disagree. What is needed is to be able to change that default of 2 seconds to whatever a user wants. Then we are still able to change individual channels from that setting. Right now as I build my Favorites Lists I have to manually edit each and every channel because I rarely use 2 seconds (but I do not want a global setting either).

I believe (or I interpreted) Jon's request as a global deafult with individual channel selections. IOW, as-is with the default of 2 seconds being user-selectable.

 

[Eng74]

One little tweet for Sentinel, have a way to center the alpha tags would be great.

 

[jonwienke]

Agreed on the global setting. Added that to the feature request list (and I will endorse that for future models even if it does not make the existing models).

Thank you. I would thing that would be a fairly easy lift, requiring only minor changes to Sentinel and the scanner firmware. I'd definitely like to see it implemented in the SDS, x36, and Homepatrol lines if possible.

For changing the delay on large groups of TGs/Channels: Change the first one. Copy that cell. Highlight all you want to change (standard windows feature using select/shift key+select or highlight and drag). Paste.

The fun part about that is when the channels are split into multiple Systems and/or Departments (e.g. WV-SIRN, VA-STARS, etc, which means that paste operation has to be done separately for each Department in each System. That's faster than changing each channel individually, but still rather time-consuming when updating a Favorite List with multiple Systems.