speed/ delay times

[Curfew]

We have several different makes of radios out there now. Im wondering if anyone knows the answer to this one, or knows the direction toward it.

Lets say we take a PRO-96 and load it up with a few trunked control channels and some conventionals. Then do the same with a PSR-500, or a Uniden model.

Now lets lock out unwanted radio traffic. When the radio is searching out new TG's, i notice that if something is heard on one TG and you command it to search, it takes a little bit for the radio to reaquire the TG you were listening to- if they are still in the same spot in the system. Or, it takes a while to aquire a new TG or the like.

This may be open to debate, and there may be bags of tricks according to each model at making the radio search out faster. Now, what is on my mind now is what is the FASTEST available digital/analog trunking scanner available when it has to circulate through lets say about 4 or 5 trunked systems, and some conventionals? This may require input with people who have more than one model to get a good idea. Thanks, C.

 

[kf4uuz]

A while ago, I had my PRO-96, and my PRO-106, side by side. I had locked out everything except three identical banks/scan lists. They were hearing the same thing at the same time. There was an occasional fraction of a second difference, but they always 'caught up' to each other.
Hope this helps.

 

[gmclam]

Lets say we take a PRO-96 and load it up with a few trunked control channels and some conventionals. Then do the same with a PSR-500, or a Uniden model.

Now lets lock out unwanted radio traffic. When the radio is searching out new TG's, i notice that if something is heard on one TG and you command it to search, it takes a little bit for the radio to reaquire the TG you were listening to- if they are still in the same spot in the system. Or, it takes a while to aquire a new TG or the like.

When a system is first going to enable a TG on a frequency, the data is sent over the control channel. If your scanner is monitoring the control channel AT THAT PRECISE MOMENT, and the TG is on, not locked out, etc; it will go to that conversation. Now press SCAN. The data on the control channel indicating that that TG is active is not typically being sent (again). The scanner will monitor the control channel data again until it either finds an active TG (perhaps the same one) or times out and moves on.

I've found that some TGs get a higher priority than others on the TRSs I monitor. For example, a transmission on a fire dispatch TG seems to get its data sent over and over on the control channel, while some typical tac channel may not. So if the TG you were monitoring was a higher priority (set by the system you are monitoring), then you are more likely to resume hearing that TG.

Unless there are scanners out there with dedicated receivers to constantly monitor a control channel, I don't see how they can behave much differently than what I've observed. The only difference would be how much control the user is given to set "dwell times" on control channels waiting for the next active TG, "delay time" to set how long to wait for the next transmission of a TG, or other such settings.

 

[Curfew]

Sort of difficult for me to explain the technicalities here. I have a a PSR-500 and i took it this morning and was listening to one TG. I hit scan and the thing cycled around and came to the same TG while it was still being used.

It took about 28-30 seconds for it to cycle through all the TG lock outs, stored TG's, and stored conventionals (very few) within 4 systems. Everything is in 4 scan lists.

30 seconds is too long when finding a TG, then the user changes to another frequency and find that.

I think all of this is a matter of how much is stored in the radio, the less, the faster. The more, the slower.

I would love to know how to speed these up while they check locked out, new, stored TG's as they come up, and have the ability to really zoom through several systems at minimum time ie 5 second minimum instead of 30 seconds.

May not be available or possible, i don't know. Thanks.

 

[gmclam]

Sort of difficult for me to explain the technicalities here. I have a a PSR-500 and i took it this morning and was listening to one TG. I hit scan and the thing cycled around and came to the same TG while it was still being used.

It took about 28-30 seconds for it to cycle through all the TG lock outs, stored TG's, and stored conventionals (very few) within 4 systems. Everything is in 4 scan lists.

30 seconds is too long when finding a TG, then the user changes to another frequency and find that.

I think all of this is a matter of how much is stored in the radio, the less, the faster. The more, the slower.

I would love to know how to speed these up while they check locked out, new, stored TG's as they come up, and have the ability to really zoom through several systems at minimum time ie 5 second minimum instead of 30 seconds.

May not be available or possible, i don't know. Thanks.

Note that talkgroups are NOT "scanned" like conventional channels. You are correct that the more conventional frequencies you are scanning, the longer it takes. That does not hold true for TGs. However, the more active control channels you are scanning, the longer it takes, just like conventional channels.

TGs are not scanned. Instead the scanner monitors the control channel data waiting for an active TG to be reported. Only when an active TG is reported does the scanner look for the TG in its list. Certainly you wouldn't want 1000 TGs in a list, which I believe is a huge reason many scanners limit the list to 150 or so. But the number of TGs in the list does not slow down scanning.

That "30 seconds" you are seeing is the time until an active TG is reported again over the control channel (re-read my prior post). I suggest reading the Wiki section here on how trunking works. You really can not compare it to how conventional channels are scanned.

 

[Curfew]

I appreciate your inputs on this one, im straight now. Makes you wonder though who makes the fastest available when considering all the angles involved. Im thinking in terms of the old Uniden Turbo scan or something that is ripping through 20 programmed frequencies back in the day, but applied to today's trunkers. C.

 

[kf4uuz]

I appreciate your inputs on this one, im straight now. Makes you wonder though who makes the fastest available when considering all the angles involved. Im thinking in terms of the old Uniden Turbo scan or something that is ripping through 20 programmed frequencies back in the day, but applied to today's trunkers. C.

When I read your above post, I immediately thought about my old Bearcat 3000. One of my all-time favorites.
I didn't know what trunking was then. I was just very happy with my amazing scanner.

 

[gmclam]

Scan speed

I appreciate your inputs on this one, im straight now. Makes you wonder though who makes the fastest available when considering all the angles involved. Im thinking in terms of the old Uniden Turbo scan or something that is ripping through 20 programmed frequencies back in the day, but applied to today's trunkers. C.

I was just reading the manual on the PSR-300 and they claim 60 channels per second. Considering the scanner has 10 banks of 100 channels, that's pretty slow. I don't think they intend for people to have all 10 banks on at once.

When I added CPUs to older crystal controlled scanners, one issue that came up was setting the scan speed. I found that a speed faster than 125ms (8 channels per second) would cause a significant decrease in sensitivity. Of course modern digital PLL scanners do not have the same issues of having to wait for each channel's crystal to "fire up". But there still is the issue of turning on a channel and waiting long enough for the signal to be detected; the time is not zero.

Trunked systems are a whole new game. Now the scanner can just sit and monitor a single frequency decoding data looking for a "good" TG. The speed of the scanner in this case is not part of the equation. The issue has to do with WHEN the TG data is sent. Mixing conventional and trunked on the same scanner just makes the situation worse, because the scanner is not constantly monitoring the control channel. That's one of the reasons I use a separate scanner for trunked and another for conventional. I miss much less, especially from the trunked systems, that way.

 

[Curfew]

Good idea with one for trunked, the other for conventionals. Would be nice to see faster processing of the trunked systems as it's checking status of priority and low-priority TG's going on at different times, checking what is locked out, checking what is new, etc. If im not mistaking the scanner is doing all of this and there is a degree of latency involved with the processing times involved.

Now that the technology is there, lets look into speeding up the processing when listening to multiple systems. I think you can possibly admit more can be done to make it more instantaneous. C.

 

[gmclam]

trunked radio 101

Good idea with one for trunked, the other for conventionals. Would be nice to see faster processing of the trunked systems as it's checking status of priority and low-priority TG's going on at different times, checking what is locked out, checking what is new, etc. If im not mistaking the scanner is doing all of this and there is a degree of latency involved with the processing times involved.

It can't work that way unless the scanner has a dedicated receiver for the trunking control channel.

In a conventional system, the scanner selects the 'next' channel and waits for a pre-determined time to see if there is a signal present. If not it moves to the next channel. Very basic and lots of places to enhance.

In a trunked system, the scanner SITS on the control channel decoding data. WHEN info for an active TG comes in, only then does it scan its list of TGs to see if the user wants to hear it. The order of TGs in the listing has nearly zero affect. The thing that dictates a more-or-less priority of a TG is how often info is sent regarding it over the control channel.

Now that the technology is there, lets look into speeding up the processing when listening to multiple systems. I think you can possibly admit more can be done to make it more instantaneous. C.

Most people are not willing to pay for this because it would take a dedicated receiver inside the scanner for each control channel you want to constantly monitor. Just to monitor ONE TRS would require TWO receivers so that one is still listening to the control channel for a 'higher priority' TG while you're hearing an active conversation of another TG.

 

[Curfew]

Thanks gmclam. I take it if we lined all of the trunking scanner makes up and had them all in sync, they would all stop on the same TG more or less in the same amount of time as what was mentioned by Kf4uzz in a previous post above with taking 2 different models and doing this ?

 

[gmclam]

trunking test

Thanks gmclam. I take it if we lined all of the trunking scanner makes up and had them all in sync, they would all stop on the same TG more or less in the same amount of time as what was mentioned by Kf4uzz in a previous post above with taking 2 different models and doing this ?

I have certainly done that with a PRO-92, PRO-95 & PRO-97. But they are really the same model with enhancements over the years.

To do this test, program only the active control channel frequency. Do not program any other frequency, make sure PRIority is off as well as anything else that might cause the scanner to momentarily leave the control channel. I either only programmed that one frequency in a bank or locked out the other 99 channels. I also only left that one bank on.

Then press SCAN and go for it!!!

 

[UPMan]

If "scanning" a single trunked system, then all scanners should behave about the same (since as mentioned several times the channel acquisition time is determined by the control channel data, not the scanner). There is some slight variation in how long different scanners will dwell on a control channel if multiple systems are being scanned. Generally, you need about 1 second to ensure you get most/all channel grants and updates (but how busy the system is affects the data volume and therefore the needed dwell time...). In theory, a scanner could miss an active but desired channel if it hit the control channel right after a channel grant but did not dwell on the control channel long enough to catch a channel update for the TGID.