• If posting about a radio issue: Include the HOST, DSP and UCM/secure firmware versions, flashcode and CPS version you're using along with the operating system info. This is critical information.

APX7000 scanning issues

Status

Jay

Prolific Contributor
CS Forums $upporter
Joined
Feb 13, 2012
Messages
166
I'm replacing my trusty XTS3000 that I used to scan some local systems with an APX. The systems are 800 MHz 3600 baud digital systems...Nothing fancy. I took the 3000 codeplug, did a drag and drop to 5000 and then ran that through the APX converter to get it into the radio. At a glance, it seemed to be working fine. But if I put the 3K and 7K side by side, the 7K seemed to be missing transmissions and also behaving strangely. The 3000 will hear tranmissions that it does not, and it will also look like it is attempting to follow transmissions and flash rapidly between that talkgroup and the conventional channel channel that the radio is actually parked on. The 7K has recent firmware.

I've messed with the scan config -> wide settings to no avail. The scan type is multi-system talkgroup but only has trunked talkgroups in it.

Open to ideas to get it working properly...Thanks!
 

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
5,020
Firmware version?
 

Magnus

Prolific Contributor
CS Forums $upporter
Joined
Dec 12, 2011
Messages
1,240
Simple things first, what is the origin of the radio? And has the tuning been checked? Every one of the tag-less radios I have seen could use some work in the tuning area.
 
OP
Jay

Jay

Prolific Contributor
CS Forums $upporter
Joined
Feb 13, 2012
Messages
166
Firmware is 7.00.10. Mangus, that is a possibility that I have considered, I do not know the origin very well.
 
N

Neo

Not Registered
Sounds like the APX is not programmed properly for your trunking system. I don't trust the APX converter, as some values are NOT transfered. As we know all it takes is one setting to be incorrect and the radio will not work properly.

I would open the Astro CPS and the APX CPS and go field by field in the trunking configuration to make sure everything is proper. As we all know Moto CPS has been known for bugs.
 
OP
Jay

Jay

Prolific Contributor
CS Forums $upporter
Joined
Feb 13, 2012
Messages
166
So for troubleshooting, I ran another codeplug through the converter, which is one that is a little simpler, and actually signs onto the system in question with a legit ID. Side by side, the xts3000 and the APX track the same channels with scan lists setup the same. The 3000 is monitoring hidden talkgroups, while the APX is signed on. Leads me to think that alignment is OK, and that the APX converter tool really butchers some data as it goes through it.

Hopefully, tomorrow will give me some time to write some of this stuff by scratch into the APX. It's gonna be a biatch starting from scratch.
 
OP
Jay

Jay

Prolific Contributor
CS Forums $upporter
Joined
Feb 13, 2012
Messages
166
Ok here is an update.

I created from scratch a codeplug that is scanning a few talkgroups. Same behaviour as before, so my theory about the converter tool goes out the window. I'm trying to listen to one site, via one conventional channel with one multi system scan list assigned to it.

Any other ideas out there?
 

Avery Johannssenn

Prolific Contributor
CS Forums $upporter
Joined
Feb 17, 2012
Messages
293
I had the same issue with my APX6000. It was inconsistently missing parts of transmissions. Sometimes it was working just fine- other times, it would miss a field unit clearing and only catch the dispatcher responding. This was also utilizing multi-system scan.

FW 7.00.10
Passive SmartNet with no affiliation.
 

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
5,020
The audio holes sound as if they're being caused by non-affiliation. When you listen passively, you also only hear what a scanner listener would hear. If a user isn't affiliated on the tower (control channel) your APX is currently monitoring, you will not hear audio. The same applies to strong-signal roaming. If you have several towers (CCs) within range of each other, and radios are bouncing around, it's quite possible at some point, you will lose (even if only for a few seconds) audio on a talkgroup. This happens all the time on the system I listen to.

I was at a BBQ last weekend. Some on-duty medics were with us. I had my MTS2000 sitting on the table, scanning the local talkgroups. They shut their radios off (to save battery) and wanted to use mine to monitor for dispatch calls. I had to explain to them why that would NOT be a great idea, as they had both just deaffiiated themselves from the tower I was monitoring. They were the only two RIDs monitoring their dispatch talkgroup, on the tower. No affiliation = no talkgroup activity.

You would not want to use the passive-scan trick to monitor CRITICAL communications. The holes are a minor inconvenience to the hobbyist. We have to live with them.
 

Avery Johannssenn

Prolific Contributor
CS Forums $upporter
Joined
Feb 17, 2012
Messages
293
I should point out that I've observed this issue whilst listening to a main simulcast site. My 346T picks up transmissions instantly and consistently, and the APX6000 will miss the first part. Both radios are listening to the same site.
 
OP
Jay

Jay

Prolific Contributor
CS Forums $upporter
Joined
Feb 13, 2012
Messages
166
Same situation here. I'm listening to a single site, the way I've plugged in the control channels. With the two radios side by side, the APX isn't consistently passing the audio and sometimes the display looks like it is having a seizure with it alternating between the conventional channel and TG's.

I should point out that I've observed this issue whilst listening to a main simulcast site. My 346T picks up transmissions instantly and consistently, and the APX6000 will miss the first part. Both radios are listening to the same site.
 

Magnus

Prolific Contributor
CS Forums $upporter
Joined
Dec 12, 2011
Messages
1,240
After reading these last posts I think it has to do with the amount of time the multi system scan is looking at the conventional channel.
 
OP
Jay

Jay

Prolific Contributor
CS Forums $upporter
Joined
Feb 13, 2012
Messages
166
Is there a way to change that? The conventional channel is not in the scan list. Multi system scan is the only scan type that CPS will allow for this setup.

After reading these last posts I think it has to do with the amount of time the multi system scan is looking at the conventional channel.
 

Magnus

Prolific Contributor
CS Forums $upporter
Joined
Dec 12, 2011
Messages
1,240
Crank up the system search time in the scan wide, trunking configuration. See if that makes a difference.
 

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
5,020
If you don't care about the conventional channel -- and are just doing this for non-afiliation trunked scanning, crank the system search time up to 255.
 

smackdaddy

Contributing Member
Joined
May 16, 2012
Messages
70
What impact does the maximum system search timer have if you have multiple different trunked systems in your multi-system scan list? Does it spend 255 seconds on the control channel for a given system, before proceeding with the next trunking system? Or does it simply adjust the balance between the trunked systems in your list and the selected conventional channel?

Cheers,
SD.
 

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
5,020
What impact does the maximum system search timer have if you have multiple different trunked systems in your multi-system scan list? Does it spend 255 seconds on the control channel for a given system, before proceeding with the next trunking system? Or does it simply adjust the balance between the trunked systems in your list and the selected conventional channel?

Cheers,
SD.
In my opinion -- and take it for what it is, scanning multiple trunking systems (control channels) is always crappy. You WILL miss calls.

The control system search time sets the amount of time a radio will monitor a control channel or system, before it moves to the next scanlist member (conventional or another control channel) to look for activity.

Each time there's a talkgroup hit (activity), the system search timer is reset. This means if it was set for 255, and it was 197 seconds into waiting for activity, the timer is now reset to 255 seconds again, once it hits on the talkgroup activity. On a busy system, this is equivalent to NEVER searching for conventional channel activity or in the case of a second trunking system, the radio will never make it there.

Set the timer too short, and you'll miss comms on each trunking system as it can't possibly hear all OSWs (for active talkgroups) within 1-2 seconds. That's just the way it is.

You should use separate radios for each trunking system, you wish to monitor.

Again, only my opinion. I'm sure others also have valid input.
 
OP
Jay

Jay

Prolific Contributor
CS Forums $upporter
Joined
Feb 13, 2012
Messages
166
If you don't care about the conventional channel -- and are just doing this for non-afiliation trunked scanning, crank the system search time up to 255.

Crank up the system search time in the scan wide, trunking configuration. See if that makes a difference.

I think this may have had some minimal impact, but am still missing a huge chunk of transmissions. The XTS will be decoding audio, while the APX is alternating between the conventional channel and the talkgroup that the XTS is hearing. Or, it will just be parked on that TG, but not unmuting to the audio.

I've been over the codeplugs again...Both I have written from scratch. The only difference I can see is that the APX scan type is multi-system (even though I am only scanning one system), and the XTS type is talkgroup. :bang: :bang: :bang:
 
Status