SDS100/200 handling of patched/multi-selected traffic

[AZhummer]

Hi all,
Sorry - it wouldn't let me post to the Uniden section. I was wondering how the SDS100/200 compares to Unication in handling of patched or multi-selected talkgroup activity. On my Unication G5 if a dispatcher has talkgroups patched, it appears to "behave" as it does on actual radios.. I can be locked on ID 1007 and hear radio traffic patched or multi-selected to ID's 1001, 1004, and 1007.. (so theoretically I could also be locked on 1001 and 1004 and hear the patched/multi-selected traffic).

I was wondering if the Uniden SDS100/200 behaves any differently.. I believe non-Type II on Uniden requires scanning all talkgroups involved in a patch and the patch radio traffic will 'randomly' pick one of the talkgroups its patched/multi-selected to - to carry the audio.

Obviously, in the old days - for type II systems you can use the status bits to better "catch" hot tones that are multi-selected (ID + 7).

Hope this makes sense.. Thanks in advance!
azhummer

 

[ofd8001]

I'm pretty sure that if at least one of the patched talkgroups is active (not avoided, etc.) you will hear everything. As I understand it, patching "kind of" joins or links those patched talkgroups into one. Patching is done so that units involved with a given event such as Police, Fire and EMS can hear each other during the event, who would otherwise be on their own talkgroup.

On multi-select, the dispatcher is heard by all the units on each of the involved talkgroups, however, the units from one talkgroup would not hear the units from another talkgroup. You would have to have one of the involved talkgroups active. This situation is useful when a dispatcher has information to share with a number of units who may be using different talkgroups. For example a tornado warning is issued that needs to be passed on to Police, Fire and EMS units, each of which is on their own talkgroup. Instead of saying the same message 3 times, the dispatcher can multi-select the talkgroups and state the message just once.

 

[Ubbe]

In most systems when a patch are done the system will continuosly inform on the control channel that TG X are now TG Z and TG Y are now also TG Z. In a multiselect the system only sends that info while the dispatcher pushes the multiselect button.

If it where a patch or multiselct that included lots of TG's it would take up huge resources but the system makes all those users come together on one common TG. That TG are in a reserved and exclusive range in the TG list and a monitoring device that monitores TG X needs to decode that patch information on the control channel to be able to also monitor that TG Z call and preferable also to display TG X on the display together with some sort of patch information to the users to let them know that they will transmit to other patched TG's.

There have been a history of added features and bug fixes from Uniden to handle patches so it is a valid question what the current status are using the latest firmware and with different system types.

/Ubbe

 

[phillydjdan]

I cannot speak for the SDS series specifically, since I don't have one, but I do have a 996P2, 536HP, 396XT, etc and those models do not adequately handle patched/multi-selected talkgroups. In fact, the 536HP didn't play any multi-select talkgroups no matter what I tried. Just some food for thought.

 

[Ubbe]

Then we can assume that the SDS series works in the same way as the 536, as the firmware have been ported from the 436/536 and most system related firmware changes have been done to both x36 and SDS at almost the same time.

/Ubbe

 

[werinshades]

I cannot speak for the SDS series specifically, since I don't have one, but I do have a 996P2, 536HP, 396XT, etc and those models do not adequately handle patched/multi-selected talkgroups. In fact, the 536HP didn't play any multi-select talkgroups no matter what I tried. Just some food for thought.

What service type is the patched/multi-selected talkgroups programmed as? Is that service type checked in the profile? No issues with patched/multi-select here with x36hp/SDS series of scanners but I program my own and have it under "Interop" with appropriate service type enabled.

 

[phillydjdan]

My specific case is the Philadelphia P25 Phase 1 system on the Fire Dept side. Same service type for all of the involved talkgroups. They multi-select when cross-dispatch fire and EMS units on the same run or when dispatching a run near the dividing line between the North and Sound geographic boundary. They can dispatch a box assignment and my 536 doesn't pick up the announcement at all. The responding units suddenly all go responding right after the other and ai find myself going "where the eff are they going?!" I solved that issue by taking the 536 off of that system entirely. *Shrugs*

 

[IAmSixNine]

And you are sure its not LSM causing you to miss the transmissions? Or maybe something specific to that system?

ON my SDS100 i monitor a P25 P1 system that often patches departments together especially when alerting. I am also running trunker on the same system and see the patches going on and off and my 436 and SDS100 never miss a beat.
I also monitor a P25 P2 Harris system where they patch and use Multicast and the only glitch there is when they patch sometimes my KGN2 will not pass audio but my scanners do.
I also monitor a Type 2 analog system that dispatches county units, and the county channel will patch to the city channels during dispatch then unpatch when the whole dispatch is over. SDS100 and 436 again do not have an issue with those.
I believe the scanners can monitor these types of situations as long as they have clean signal to decode the control channel and properly get channel grants.

 

[phillydjdan]

Not LSM, I ran that scanner with a yagi pointed at only 1 tower to remedy the LSM issue. With the exception of multi-selected transmissions, reception was flawless. I was one of the ones that pioneered the yagi approach back in 2013ish.

 

[werinshades]

Not LSM, I ran that scanner with a yagi pointed at only 1 tower to remedy the LSM issue. With the exception of multi-selected transmissions, reception was flawless. I was one of the ones that pioneered the yagi approach back in 2013ish.

Are all scanner users including SDS users in the area experiencing the same issue? Is the talkgroup affiliating with another site that you don't have programmed? As mentioned, simulcast issues could be the culprit.

 

[phillydjdan]

I don't have every scanner owners email addresses or phone numbers, so I can't answer that. The bottom line is the HP line of scanners is trash. It's well documented. Motorola works the best. That's what I use now. Carry on amongst yourselves

 

[werinshades]

I don't have every scanner owners email addresses or phone numbers, so I can't answer that. The bottom line is the HP line of scanners is trash. It's well documented. Motorola works the best. That's what I use now. Carry on amongst yourselves

Did you ask in the local forum? This doesn't sound like a scanner issue, but a programming and/or simulcast issue. Scanners work as advertised, but can't compare to a commercial two-way radio. I checked the system you're having "issues" with, all simulcast as I suspected, and a couple potential sites could be in use. You're Motorola radio has been programmed properly, but you're 536 doesn't handle simulcast systems well...as also documented.

 

[jonwienke]

Some people just enjoy peeing on the electric fence.