APX Mixed Scan List: issue with taking +20 seconds to land on an open conventional/analog freq

[BudTurpa]

Running an APX 8000 (R14).

A Scan List contains three members:

#1 A Conventional Zone/Channel (NAS config for a Astro P25 Talk Group)
#2 A Conventional Zone/Channel on a "pure" conventional analog freq (CSQ, railroad)
#3 A Conventional Zone/Channel on a "pure" conventional analog freq (CSQ, fire dispatch)

The behavior is that anytime there is traffic on (#1) the NAS/TG entry the radio lands and opens just fine. No traffic is missed.

When there is traffic on either of the two pure analog frequencies (#2 or #3) the radio will only land and open if the transmission time is at least 20 seconds. In those rare cases the radio stays on the channel (#2 or #3) till the carrier drop (and the hold over time) and then returns to scanning. Hence, I am missing 99% of the traffic on #2 and #3 since the transmissions are rarely +20secs long.

What this is telling me is that there may be a configuration I have overlooked and the APX is has a set time period (like 20secs) to leave the active Trunked Talk Group session before moving on down the list to scan other channels.

Contrary to what someone like me would normally set, 200+ seconds, so the APX stays on the same control channel, I actually want it to leave the Control Channel and move on to other entries in the Scan List. I've experimented with "System Search Time" on the Scan Wide page with 1 secs, 3 secs, and 200 secs. In all three cases the radio still seems to not be "moving on" down the list after #1 goes in-active for about 20 seconds.

Can anyone suggest what's happening? What other timer settings I need to pay attention to? Any chance this is an older firmware of R14 issue?

Thanks

 

[ElroyJetson]

I am going to speculate. Are you SURE you are doing NAS correctly? I'd suspect a trunking configuration issue.

I don't even get why you're doing it this way anyway. If you want to listen to the foamer channels, just set up a conventional scan list and scan them directly.

NAS was never created with the intention of scanning conventional channels or mixing conventional and trunked channels in the same list. It's for using a conventional channel as a launching point for scanning trunked talkgroups via a mode slaved scan list consisting exclusively of trunked talkgroups.

You're in uncharted territory.

There are a number of parameters that could be involved in your issue and I'll bet that they all involve trunking and digital configuration items.

 

[BudTurpa]

I am going to speculate. Are you SURE you are doing NAS correctly? I'd suspect a trunking configuration issue.

I don't even get why you're doing it this way anyway. If you want to listen to the foamer channels, just set up a conventional scan list and scan them directly.

NAS was never created with the intention of scanning conventional channels or mixing conventional and trunked channels in the same list. It's for using a conventional channel as a launching point for scanning trunked talkgroups via a mode slaved scan list consisting exclusively of trunked talkgroups.

You're in uncharted territory.

There are a number of parameters that could be involved in your issue and I'll bet that they all involve trunking and digital configuration items.

Hey Elroy, I can't say I am 100% certain on my NAS programming, but I've got roughly 30 TGs across multiple systems programmed and they work correctly. All my Scan Lists that are only NAS Zone/Channel entries also work perfectly. It's only the first time that I am trying to combine a NAS channel with a pure conventional/analog channel that I am running into an issue. I do lug around two radios - one for NAS and one for foaming, my wife loves it. Trying to get down to a single radio.

 

[ElroyJetson]

I think you've answered your own question. Sort of. It appears that the radio has difficulties mixing conventional analog and trunked digital talkgroups in the same scan list.

It takes a little time for the radio to scan to a trunked system and lock on to it. Now ask it to change off that trunked system, switch to conventional mode. scan, and then go back to listening to the trunked system control channel, lock to it, and begin listening for the talkgroups in your scanlist again.

There's a minimum time it takes for the radio to scan for a trunked system and lock to it, whether it affiliates or not. To do that, then scan a conventional channel, then go back to scanning the trunked system, over and over and over again, has to be a slow process.

If the radio isn't parked on the control channel and listening, it's not going to hear ANY trunked talkgroups. It doesn't have the capabilty to simultaneously monitor the CC and also scan conventional channels.

This is not a recommended configuration. Because it doesn't work well.

 

[willdanl]

Does your scan list point to the zone/channel containing the actual trunking TG (on ch 17+ in some zone), or does it point to the zone/channel of the conventional channel that scans the TG in another NAS zone? Does what I’m asking make sense?

I have several zones for NAS, each for a different system. I have 1 conventional channel set up in another zone that scans a scan list containing just a couple of TGs from 3 different systems. Realize it’s a little different- not mixing in conventional - but it works beautifully. Under scan wide, trunking I have system search time set for 2 sec.

 

[mikewazowski]

What is the Trunking System Search time in your Scan Configuration/Wide set to?

I have no problems scanning a mix of conventional and trunked channels on my APX.

 

[ElroyJetson]

How quickly does your radio respond to calls when scanning in mixed mode? I'd like to know for informational purposes.

I've never actually had any personal need to set up mixed mode scan lists.

 

[jeepsandradios]

I have seen the same issue with a on network and affiliated radio using "talkgroup" scan. We would monitor our direct Analog Fire Ground and it would miss half the info consistently. We were told not to mix trunk and conventional. While it did work it was just very slow.

 

[BudTurpa]

Does your scan list point to the zone/channel containing the actual trunking TG (on ch 17+ in some zone), or does it point to the zone/channel of the conventional channel that scans the TG in another NAS zone? Does what I’m asking make sense?

I have several zones for NAS, each for a different system. I have 1 conventional channel set up in another zone that scans a scan list containing just a couple of TGs from 3 different systems. Realize it’s a little different- not mixing in conventional - but it works beautifully. Under scan wide, trunking I have system search time set for 2 sec.

The Scan List contains the actual trunking TG (on ch 17+). But that's a good point, that I never thought of, some people might be having issues because their Scan List contains the conventional channel that scans the TG in another NAS zone. I appreciate you making me think about that.

So as it happens often, I make multiple changes to my code plug and then all of a sudden things start working. Since I didn't make the changes methodically it's hard to determine what fixed my issue. All that to say, after 12+ months of trying to figure this out, I got it working. My mixed Scan List (with a TG and multiple analog channels) is now stopping and landing on all the entries in my Scan List perfectly. I don't have that 20 second delay before the radio leaves the TG to look for traffic on the analog channels.

Here's what I played with over the weekend - maybe you might know if anything I touched is related to my previous issue.

I changed the trunking system Coverage config from Disabled to SmartZone/OmniLink. With a wide area simulcast as the only interest, this worked in Disabled.

I loaded the radio with a bare bones code plug (nothing of substance in it), then re-loaded my working code plug. This was an attempt to set the radio back to "factory settings". I know this really doesn't exist, so I made it up. This might have been a waste of time, it was my attempt to overwrite any lingering odd code plug elements that might be getting in the way.

I re-ordered the Scan List to have the TG in the first entry, the analog channels in entries 2, 3, etc.

Last, in addition to the control channel and two alternate control channels that I previously had, I added all (like 15 more) of the RR listed freqs (the black colored ones) to the Control Channel list. I have never know what those (black) freqs are used for, so I added them.

Then an odd thing happened Sunday. All of my radios were overloaded (what I am calling it). Upon power-up the squelches opened and a bunch of "digital static" came on the speaker. It happened all day across multiple radios. I heard no real radio traffic all day. Monday that was gone and then everything was back to normal and my mixed scan started to work.

 

[IFRIED91]

Always always always remember…and this applies to any radio/scanner if u add conventional channels to a scan list which monitors TGs on a trunking system.. you’re telling the device to stop what it’s doing and look away from the control channel and then essentially has to go back and re-aquire the information supplied by a control site… technology has some limitations here