SDS100 "ID Scanning" holding up scan

[donirving]

Hi All,

I'm scanning "SVRCS", a Silicon Valley area Motorola P25 Phase II system, and the scan hangs for several seconds on each of two sites saying "ID Scanning". I have “ID Scan” and “Priority ID Scan” off for that system, plus there are no channels in the scanner with priority set. "ID: Search" is also off, although I have toggled all of these both ways. I've read about Motorola system ID priority, but I have turned off everything that I think should make the SDS100 pay attention to that. Or maybe the "IS Scanning" indication on the scanner has to do with something else.

It it perhaps something else? I'm scanning 6 departments with a total of < 10 TGIDs total among them. I am scanning only the red/blue (in RR) control channels, having removed the others from the sites. I am scanning ~15 conventional channels in their own system/departments. The conventional channels scan in an a flash of the eye, then the scanner sits silent for up to 10 seconds on SVRCS saying "ID Scanning".

I would greatly appreciate any help.

thanks,
Don

 

[UPMan]

The scanner will spend 1.5-2 seconds on each enabled site within the system (assuming no traffic of interest). This is regardless of how many TG's are being checked. Removing the non-control channel frequencies isn't necessary and doesn't really help anything (could hurt if one of the freqs not documented as a control channel becomes the control channel, which can happen).


While the scanner is dwelling on a site, what it is doing is watching for all the channel grants/updates coming across on the control channel and comparing them to the TGs you are interested in hearing. If one matches, then the scanner jumps to the frequency assigned to that TG. If none match, it moves on to the next site. It takes 1.5-2 seconds for a control channel to cycle through all activity (thus the 1.5-2 second dwell time).

 

[donirving]

The scanner will spend 1.5-2 seconds on each enabled site within the system (assuming no traffic of interest). ...

Thank you, Paul, for explaining that. Re the non-control frequencies, I’ll go ahead and add them back into the sites. And re your (excellent) explanation about the long dwell problem, I understand it now, thanks.

But I guess that means that there is not really any solution for listening? I have to figure out some way to mitigate the problem so I can reasonably scan other (conventional) channels. The dwell is often more like up to 3 seconds on each site meaning that it often does not get back to my conventional channels for up to 6 seconds. I don’t mind using a separate scanner for conventional. Actually you can hear more with two (three, four, …) scanners anyway. (based on my full-geek experience with six (seven if you count my Bearcat IV) in our home office.)

Paul, after explain this well, I don’t expect you to take more of your busy time continuing with this thread, but maybe others can pipe in about it how to mitigate this problem?

Many cheers!
Don

 

[Ubbe]

No, there's no solution other than using multiple scanners and/or radios to monitor multiple systems. A scanner needs, at least a Uniden on DMR systems, to dwell 3 seconds on a control channel to really sync and be able to properly decode the ongoing transmissions.

As voice channels in a trunked system only transmits a carrier when in use with a conversation you could SQ scan them and if there's no conversations on that site it will be skipped in milliseconds, a technique that Whistler uses that can be favorable with some systems, if you can exclude the control channel frequency from being scanned.

/Ubbe

 

[donirving]

As voice channels in a trunked system only transmits a carrier when in use with a conversation you could SQ scan them and if there's no conversations on that site it will be skipped in milliseconds, a technique that Whistler uses that can be favorable with some systems, if you can exclude the control channel frequency from being scanned.

/Ubbe

Thanks Ubbe, I thought about something like that, but wouldn't I loose the continuity of conversations if they moved around switching multiple conversations and I didn't have a good way to follow just the one(s) that i wanted? But I guess what you may be saying is that I should look at options for filtering on TGIDs or something? But I can't imagine how one would dynamically lock out (sorry "avoid") the currently in use control frequency.

I read about "scan the traffic channels" thing on the Whistler forums while I was evaluating the TRX-1. I will read again to figure it out.

Thanks for the lead!

Don
(I guess I should come up with a sig.)

 

[ofd8001]

You might double check the programming for your system (under the Options tab) and see if any "extra" hold time (>0) is being added. You could drop it to 0 if there is and see what happens.

You could also set up Priority Scanning for your conventional frequencies. If I remember correctly, if there is a transmission on a Priority conventional frequency, the scanner will jump off listening to the control channel to monitor that active conventional frequency. Of course the trade off is you might be listening to a "good" conversation on the trunked system, only to jump off for the conventional frequency. (The reverse isn't true however - the scanner won't jump off a conventional frequency to check for Priority talkgroups on a trunked system. "Priority scanning" on a trunked system is a whole 'nother creature.)

 

[donirving]

You might double check the programming for your system (under the Options tab) and see if any "extra" hold time (>0) is being added. You could drop it to 0 if there is and see what happens.

I think this did it! The reason I say "think" is that I also at that time made a couple other changes, which I don't recall. In any case it is now down to 1 second per site or less, which is a total of about two seconds on the trunk System before continuing. That's still not ideal, but at least scan-able. I will continue tweaking to see if there are any other settings that seem to affect things.

The root duh: When I first programmed (in Sentinel) I changed the System level delay to 2 seconds thinking that it was just setting the default for channels. Thanks for pointing out that this is "extra" delay!

Cheers,
Don

 

[W8RMH]

I think this did it! The reason I say "think" is that I also at that time made a couple other changes, which I don't recall. In any case it is now down to 1 second per site or less, which is a total of about two seconds on the trunk System before continuing. That's still not ideal, but at least scan-able. I will continue tweaking to see if there are any other settings that seem to affect things.

The root duh: When I first programmed (in Sentinel) I changed the System level delay to 2 seconds thinking that it was just setting the default for channels. Thanks for pointing out that this is "extra" delay!

Cheers,
Don

As stated in post #2, "The scanner will spend 1.5-2 seconds on each enabled site within the system (assuming no traffic of interest)."

 

[JoeyC]

Some people program way too many sites into their systems than they need. Avoid all but the one you need to hear whatever you want to hear. In many cases, you might only need one site. This will limit the amount of time the scanner stays on one trunked system.

Programming voice channels also, accomplishes nothing, unless you wish to conventional scan the trunked system frequencies in which case you would have troubles following a single conversation.

 

[donirving]

Some people program way too many sites into their systems than they need. Avoid all but the one you need to hear whatever you want to hear. In many cases, you might only need one site. This will limit the amount of time the scanner stays on one trunked system.

Programming voice channels also, accomplishes nothing, unless you wish to conventional scan the trunked system frequencies in which case you would have troubles following a single conversation.

Thanks Joey,

There are two main regional sites plus a third one just coming up. They are on different frequencies with different agencies and traffic. So I do, unfortunately, need to scan them both or all. They seem to me to be gearing up for simulcast since they have gobs of new licenses for buildings and hill-tops. But it looks to me, from the license frequencies and locations, that they intend to keep the three regional areas separate and simulcast separately in each one. I don't know with any authority about any of this, just guessing.

The voice channels just come along for the ride when you grab a site from the SDS100 copy of RR. I actually deleted them at first until UpMan said to not bother since they don't slow anything down. It is interesting that the TRX-1,2 can apparently scan just the traffic channels and grab the talk groups you want from them.

Thanks again,
Don

 

[ofd8001]

I have the understanding that simulcast systems use the same frequencies at several different site/transmitter/tower locations. So I'm scratching my head when you mention more frequencies.

They could be adding more voice channels because folks are getting "busy signals" when trying to transmit. Or they could be adding more sites, but on different frequencies.

Unfortunately the "delay" time in scanning trunked systems is the nature of the beast and a bullet has to be bitten.

 

[donirving]

I have the understanding that simulcast systems use the same frequencies at several different site/transmitter/tower locations. So I'm scratching my head when you mention more frequencies.

They could be adding more voice channels because folks are getting "busy signals" when trying to transmit. Or they could be adding more sites, but on different frequencies.

Unfortunately the "delay" time in scanning trunked systems is the nature of the beast and a bullet has to be bitten.

Hi ofd,

It is currently three separate, radio sites, "West", "Central", and "South" spaced around the county. They are tied together in some manner that I do understand. However, each site has its own, mutually exclusive set of control and traffic frequencies. (I think there may be one freq dup, but I don't remember.) ) It is the SVRCS trunking network for Silicon Valley (Santa Clara County), which you can check out on RR .

I know that they are planning many, many more sites sprinkled around the county. This is based on my FCC license searches. Most new sites (according to the licenses) will have the same set of frequencies as the current site that they are closest to. (mountain tops don't seem to follow this.) So they are clearly retaining the three "zone"? "cell"? model with some sort of voting or simulcast within each. I really have no idea what they are actually planning except that the FCC licenses speak for themselves about locations and frequencies.

I have yet to introduce myself on the SVRCS forum because you guys are keeping me so busy here But they have been with the system since it started, and know much more than I do.

And it's just a bitter pill that I have to swallow about delays

Cheers,
Don

 

[donirving]

As stated in post #2, "The scanner will spend 1.5-2 seconds on each enabled site within the system (assuming no traffic of interest)."

Yes, I am coming to grips with that sad fact, but I am still looking for other tweaks to reduce delay time of any sort. Changing the system delay to 0 helped considerably with no ill effects that I have noticed.

There is also Digital Waiting Time, which I have not changed yet, but I believe that there are no mixed systems here, so perhaps it is not needed. Or perhaps it will make no difference to user experience. Or perhaps I think I understand it but really don't

Cheers,
Don

 

[donirving]

I'm scanning "SVRCS", a Silicon Valley area Motorola P25 Phase II system, and the scan hangs for several seconds on each of two sites saying "ID Scanning". I have “ID Scan” and “Priority ID Scan” off for that system, plus there are no channels in the scanner with priority set.

This is a reflection on part of my original thread post. When I saw "ID Scanning" my mind went to UID or some other type of ID, not Talk Group ID. I guess I expected that since there are more than one "ID" to see Talk Group qualified as such Things make much more sense now that I realize that it means TGID Scanning.

Thanks for eveyone who has helped me.
Don