Batboard

Ok, this is kind of weird, but I think its a bug.

My friend who is a LEO for a big agency was showing me his new APX 7000 this week and complaining that it doesn't act right while scanning. He's on a large P-25 trunking system.

So he tells me that sometimes its fine, but that other times it won't delay on a channel.

This took me a long time to figure this out by messing with his scan list (just with the keypad because I don't have the key to be able to read or program). Anyway, it looks like the problem happens when there is a talk group in the scan list that is patched to another talk group. This is something that is pretty common on this system.

So if there is even one talk group in the scan list that is patched to another talk group (the other TG in the list or not), the scan delay is non-existent. It will jump to another talk group right after a transmission ends. But if we take that talk group out of the scan list, it will hang on a talk group for 2-3 seconds (whatever its set to) after a transmission ends.

Its really annoying when it does it and I can see why he doesn't like it. His XTS 2500 he had before did not have the issue.

Does this make any sense and could it be anything other than a firmware bug. That's what it seems like to me.

Forgot to say, the non-existent delay happens on all the talk groups in the scan list, not just the ones that are patched.

What version firmware does the radio in question have?


-Marc

R07.00.00

I'd doubt if its a firmware bug... the subscriber has no way of knowing if dispatch has patched two TG's together; as thats an infrastructure-side proceedure, not a subscriber-side proceedure. Its more likely that the patch he's encountering is between a priority and non-priority member of his scan list, if he's on the non-pri channel and finishes a transmission and that TG is patched to a PRI channel and his PRI sampling rate is set low enough, the subscribrer probably hears the activity on the PRI channel and drops its scan hang time. (or something like that).

It'd probably be extremely hard to track that sort of thing down; but i'd doubt quite a bit if it had anything to do with the firmware acting upon the scan hang time; since the portable/mobiles have no clue what dispatch has patched/not patched. I will add, though, that the Astro25 TG scan functions leave quite a bit to be desired in the first place....

It may be a programming issue in the radio. I've used talkgroup scan and priorty system scan without issues. It may just be a simple fix. For the patched talkgroups, its possible that there is still a "carrier" delay (for lack of better terms) that is keeping the talkgroup open while there is no audible audio/voice being heard. Just depends on how its patched.

There CAN be issues with patched talkgroups. If its a console patch from a TRS to a conventional channel, you can be at the mercy of repeater hang time if audible (if repeated), audio delays and the such. On the CCGE we used to patch in legacy systems we would experience dropped/chopped audio at the begging or tail ends. If the talkgroups were patched via other means, it would be seamless.

I'm not sure. The radio shop guys are trying to figure it out now. They have other APXs doing it now too, but I think my buddy scans more than anyone and most don't notice it.

They haven't found anything in programming and they updated his firmware to the latest that just came out recently.

If you watch the display while it's scanning, when a transmission ends on a talk group, if another talk group is active in the scan list, it jumps immediately to that talk group. So you never hear the reply on the first talk group. If you delete the talk groups that are known to be patched (to other talk groups via the console - I don't think they patch to conv. channels much), then you see the normal 2-3 second scan delay.

I never realized how important a scan delay is, especially with busy talk groups - ha ha.

Oh well, it's not really my problem, just weird behavior.