APX Scanning & Codeplug Efficiency

[TurboSportTSi]

Sort of a 2-pronged question... I'm in the middle of overhauling a codeplug and the MTN published this week about issues from codeplug size over 3MB came out. The new codeplug is well over 3MB already, so I've been looking for ways to slim it down. One of the ways I came up with was to centralize our statewide mutual aid channels into one personality. Currently, most personalities have a handful of mutual aid channels in them, which defeats the point. If I removed those channels and pointed the mutual aid channels in the zones and scan lists to those same channels in the common mutual aid personality, it should save quite a bit of space. Enough? No idea, but it's a start.

Here's the rub: I'm not a Moto guy, so forgive me as I learn. It seems bananas to me how scan lists are separate entities associated to personalities instead of being determined by a simple checkbox per channel in the zone. From what I gather, if I had a zone half full of PD channels and half full of mutual aid channels (two different personalities), the radio would only scan the scan list associated to the personality of the currently selected channel.

If I were to do as I described above, separate from re-pointing the zone channels, I would also have to rebuild each scan list to mirror the zone channel line-up, and re-point the mutual aid channels to a different personality. Is that correct? Currently, the scan lists essentially mirror their respective personalities (again, bananas to do twice the work...and have twice the error potential), but once those channels are removed from the personality, they'd need changed in all scan lists. Should the common mutual aid personality not have a scan list? What happens when a user selects the mutual aid channel in their active zone? They wouldn't be scanning any of the other channels in their zone because the mutual aid channel is in a different personality???

For some reason this confused me yesterday, but after writing it out, I think I'm GTG on the scan lists and maybe my common personality idea isn't a good one in practice. I suppose it takes a special level of stupid to understand some of the things Moto does. Gotta give them credit, though...initially I thought the concept of personalities was crazy, but I'm coming around on that, to a degree, as it has its pluses and minuses.

Anyway, I'd love some input from seasoned folks on my plan - anything I missed or tips to get this done in a better way? Especially on the codeplug size. I went through and removed a bunch of prefixes in the channel names that show the channel #, but after 84 zones worth of channels that didn't do as much as I was hoping. Not sure what else to do on that front.

 

[Tech21]

Before you go cleaning house on everything, which you absolutely should do. Clean up your voice announcement files first. That's probably what's causing your codeplug to exceed the 3mb limit.

Enabling scan in the conventional/trunking personality is just making those channels/talkgroups available to put in any scan list you create.

You don't need an individual scan list for every personality.

Keep your scan list simple. Build a single Multi-System scan list and give it a 16 channel limit for your subscribers. 99 percent will never even come close to putting that many things in the scan list to begin with.

Zone channel assignment works the same way. You put the channel/talkgroup in the personality and you can then put that channel/talkgroup in however many zone channel assignments you want.

 

[ElroyJetson]

The Motorola programming philosophy is much more flexible than the GE-Harris programming philosophy, which is both a benefit and a drawback. I'm pretty fluent in both. I can ALWAYS do more in CPS than in RPM, but I can get things done in RPM faster, however, with less flexibility to configure things.

When simplifying a codeplug, start with customer requirements. See what the customer sees as luxury, what is optional, what is useful, what is essential, what is absolutely mandatory. Start with scanning. Most public safety agencies want their officers to stay on their assigned channels and not scan, which raises the possibility of missed calls. Supervisors get to scan, patrolmen stay on their designated ops channel.

Though everybody wants to have to keep track of as few unique codeplugs as possible, if the requirement is to keep codeplug size small, then the sensible thing to do is to go to each agency and have them review the codeplugs they use and delete what they don't really NEED to be in them. "Yeah it'd be nice to have those VHF marine patch channels in the event of a maritime emergency, but the truth is the largest body of water in this county is a retention pond so we can delete those 10 groups and never miss them. But the supervisor's radio will still keep them."

Same goes for multi sites. If a south side agency's officers NEVER go to the north side coverage sites, why are the north sites even provisioned into their portable radios? Keep it in the mobile radios if you need to, but take them out of radios that will most likely never need it.

And via the magic of OTAR, more full featured codeplugs can be kept ready for download to radios as need, when needed. Not that I have ANY hands on experience with that process.

 

[TurboSportTSi]

Before you go cleaning house on everything, which you absolutely should do. Clean up your voice announcement files first. That's probably what's causing your codeplug to exceed the 3mb limit.

Enabling scan in the conventional/trunking personality is just making those channels/talkgroups available to put in any scan list you create.

You don't need an individual scan list for every personality.

Keep your scan list simple. Build a single Multi-System scan list and give it a 16 channel limit for your subscribers. 99 percent will never even come close to putting that many things in the scan list to begin with.

Zone channel assignment works the same way. You put the channel/talkgroup in the personality and you can then put that channel/talkgroup in however many zone channel assignments you want.

We don't use VA, so I never thought to look there. Using someone else's codeplug as a template, there very well may be VA files that I could delete!

The single scan list is an awesome idea. I will mess with that and see if that's something that would meet our needs.

The Motorola programming philosophy is much more flexible than the GE-Harris programming philosophy, which is both a benefit and a drawback. I'm pretty fluent in both. I can ALWAYS do more in CPS than in RPM, but I can get things done in RPM faster, however, with less flexibility to configure things.

When simplifying a codeplug, start with customer requirements. See what the customer sees as luxury, what is optional, what is useful, what is essential, what is absolutely mandatory. Start with scanning. Most public safety agencies want their officers to stay on their assigned channels and not scan, which raises the possibility of missed calls. Supervisors get to scan, patrolmen stay on their designated ops channel.

Though everybody wants to have to keep track of as few unique codeplugs as possible, if the requirement is to keep codeplug size small, then the sensible thing to do is to go to each agency and have them review the codeplugs they use and delete what they don't really NEED to be in them. "Yeah it'd be nice to have those VHF marine patch channels in the event of a maritime emergency, but the truth is the largest body of water in this county is a retention pond so we can delete those 10 groups and never miss them. But the supervisor's radio will still keep them."

Same goes for multi sites. If a south side agency's officers NEVER go to the north side coverage sites, why are the north sites even provisioned into their portable radios? Keep it in the mobile radios if you need to, but take them out of radios that will most likely never need it.

And via the magic of OTAR, more full featured codeplugs can be kept ready for download to radios as need, when needed. Not that I have ANY hands on experience with that process.

I feel the same way about BK's RES vs APX CPS. Two totally different animals, with RES being very fast and user friendly, but not near as flexible or powerful as CPS.

Unfortunately, I did not receive a ton of feedback when it was solicited, but I also think it's because the codeplug template was developed by agencies that our guys work with most often, so maybe it's mostly GTG. This isn't for a PD, so our guys can basically do what they want as far as channel usage goes. They have large patrol areas and use cooperator channels exclusively, so they're always moving around the region, in & out of local jurisdictions.

To your point about unnecessary channels, though, we have identified some areas that none of our LEOs ever really go and have slated them for removal if needed. I saved a different copy of the codeplug and deleted all that stuff to get a rough order of magnitude and it only got me a few hundred kB. Those will be the first to go if we need to start chopping things, followed by a hard look at trimming other areas ( I *may* have added a bunch of our internal channels as backups....). Ounces = pounds and pounds = pain, right? Juxtapose that with rather having and not needing vs the other way around and you've got quite the philosophical predicament!

I totally agree with having codeplugs for different areas and have thought about doing that, but a big part of the reason why we're looking to standardize is because we have a small crew spread over a large area and they often travel to work with each another. Having only the local guy have the right channels isn't ideal or even safe. It's not like they can clone their local zones in the field...which would solve many problems. Not sure if I want to open the FPP can of worms either...

 

[Radio99]

Can someone either post the MTM number or a copy of it? I searched My Learning on the Motorola portal and am unable to locate it. Thanks in advance.

 

[GTR8000]

Same goes for multi sites. If a south side agency's officers NEVER go to the north side coverage sites, why are the north sites even provisioned into their portable radios? Keep it in the mobile radios if you need to, but take them out of radios that will most likely never need it.

At worst including four more control channels takes up 1 kb in a codeplug. If you're really so concerned with saving 1 kb that you would take away the ability to roam to a neighboring site, you have bigger issues. Besides, the two sites are probably broadcasting each other as adjacent, so once the radio is setup for SmartZone operation, it'll find the other site on its own anyway.

Not great advice, sounds like you're really not that fluent in real world programming after all.

And via the magic of OTAR, more full featured codeplugs can be kept ready for download to radios as need, when needed. Not that I have ANY hands on experience with that process.

OTAR = Over The Air Rekeying, has nothing to do with programming codeplugs.

 

[GTR8000]

PS - Firmware R32.03.00 addresses the subscriber reboot loop issue. If you are concerned, update the firmware.

PPS - Most of the bloat I've seen in APX codeplugs is attributed to a large UCL, not the operational parameters.

 

[TurboSportTSi]

Can someone either post the MTM number or a copy of it? I searched My Learning on the Motorola portal and am unable to locate it. Thanks in advance.

MTN-0008-24

 

[TurboSportTSi]

PS - Firmware R32.03.00 addresses the subscriber reboot loop issue. If you are concerned, update the firmware.

PPS - Most of the bloat I've seen in APX codeplugs is attributed to a large UCL, not the operational parameters.

Are you positive on R32 correcting this? It was released to correct a boot loop issue caused by the previous fw version. The MTN is a bit vague and does not specifically call out R32 as a fix action, I was under the impression that this was a new issue.

 

[GTR8000]

Are you positive on R32 correcting this? It was released to correct a boot loop issue caused by the previous fw version. The MTN is a bit vague and does not specifically call out R32 as a fix action, I was under the impression that this was a new issue.

I'm positive that the release notes for R32.03.00 specifically address the issue in MTN-0008-24.

Am I positive that MSI actually fixed it this time? 🤷‍♂️

 

[TurboSportTSi]

I'm positive that the release notes for R32.03.00 specifically address the issue in MTN-0008-24.

Am I positive that MSI actually fixed it this time? 🤷‍♂️

Copy that! I seem to recall R32 coming out before the MTN, but then again, it's Moto, so...yeah. I did not read the release notes. Shame on me!

 

[GTR8000]

Note the issue date on the MTN: 2024-01. R32 was released on Jan 17th.

 

[Radio99]

TurboSportTSi got it. Thanks much for the information.

 

[TurboSportTSi]

Note the issue date on the MTN: 2024-01. R32 was released on Jan 17th.

Oh, weird. I just got notified by MSI last week.

Edit: I guess it was ~2 weeks ago. Between work & school, I have no idea what day it is half the time.

 

[GTR8000]

It seems that they sent the MTN out well after the fix was issued in R32. Are any of us really surprised by that? Anyway, for the time being R32 allegedly fixes the issue...until the next MTN is issued, of course. 😵