APX Next

[echo5kilo]

For those who have had the opportunity to play with a Next, I'm trying to figure out if anyone else can replicate my issue or is experiencing an issue with larger codeplugs.
Programing is done via Radiocentral, a local piece of software that has a very radio management kind of feel to it. Best I can tell the radio management part is on a hosted server in moto land. Jobs are pushed to the radio via wifi or LTE. Not too ideal for disaster or remote operations, but whatever, we're demoing the product. I read on another thread about the concept of the subscription model and codplugs/programming being "none of their business". Couldn't agree more and this alone will probably kill the sale for us, but that's a thread for another day.

These is an option in the software to convert APX codeplugs to a NEXT codeplug. What I'm struggling with is what I think is an issue related to larger codeplugs. Documentation is poor to non existent for radiocentral. The software has an option to convert a traditional .mc APX codplug into a format the Next uses. I've processed small codeplugs easily through their tool, a codeplug with maybe one or two trunked systems and some interoperability conventional channels. I've got an APX codeplug that is 6.88MB with a ton of regional trunked systems, zones, etc for the general DC area and adjacent localities in MD and VA. The conversion job shows its successful, but the new codeplug never shows up in the list of configurations. Small or large, from a job processing perspective, everything appears the same. I haven't had the time to step down the larger codeplug and find a magic number, but I think the issue is related to general codeplug size, maybe system or personality limitations. Not sure yet.

Hadn't been here in a while, glad to see the site is back up and running!

 

[RadioTech]

Last time I did the RadioCentral codeplug conversion for the APX Next, it was a manual process that Motorola techs performed.
Nothing indicated so, for me, but It may be possible that your codeplug is currently being manually built by their codeplug techs. It took 2-3 days before mine showed up. Some errors were found so check it out before releasing it if its going to be used in the field.

As for the “codeplug/programming being non of their business”...I agreed but after thinking about it...what in our codeplugs is not already public knowledge? For me its AES key numbers but those #’s mean nothing without the key material. Everything else in the codeplug can be found on FCC website or Radio Reference anyway. I guess maybe not the IP address of the KMF & Data profile? Not sure what they could do with that data as it has its own built in security anyhow.

 

[sarguy1941]

I just did one this week. took 15 minutes until it showed up for me.

 

[echo5kilo]

Thanks for the feedback! The few I've tried have taken anywhere between 3 and 10 minutes to "convert" and appear as an available configuration. The larger ones show completed about 20-30 minutes later, but never show up in the configuration field. I'll keep plugging away a report back anything I learn.

As to the codeplug stuff, I guess if you can slow anyone down, if even for a moment to maintain op sec, its a win. In the long run you're right, RR has more than enough info on it to create havoc.

 

[MTS2000DES]

I'm not impressed by:
-Having to use a cloud based service that sends all my codeplugs (including crypto keys) to a third party (most likely off shore) to be "authored" that takes time
-Paying a yearly SAS fee to do it
-Paying 8K-13K per subscriber

No thanks. HEY Harris, JVC Kenwood, Tait, Relm...whatcha got?

 

[sarguy1941]

What keys are you sending ? I loaded mine with my KVL after programming before it would work.

 

[echo5kilo]

I like the managed configuration concept to push stuff to users in the field remotely, but realistically we can accomplish something very similar with the Harris XL200 at a fraction of the cost per unit using their mission plan concept. Only bummer there might be that the enduser has no idea how to find what they are looking for! When ever we do these large deployments of cache radios we set the channel and zone on the radio, give them a little flyer on what the buttons do and cross our fingers.

We're due for replacing our ageing XTS cache of about 1000 subscribers. Going multiband you get the 3:1 ratio going for you which is cool. Our use case is a disaster cache of about 500 subscribers that would require speed and agility in programing. Cool concept with the next, I just don't think at those numbers I can justify the cost in replacing a fleet of truly disaster use/non-daily use radios.

 

[ndp]

Not to mention our guys don't WANT a big ass touchscreen and all the bells and whistles. It's an uphill battle to do in-service on radios with significantly less features - making it 100x more complicated is exactly the opposite of what the fire service needs.

I don't need text messaging. I don't need an app store. I don't need a virtual assistant. I need a radio that performs well, is durable enough for the fireground, and above all else is not complicated to use. We expect these guys to be experts in so many different fields - prehospital medicine, structural firefighting, wildland, US&R, extrication, etc, etc, etc. I want the radio to get what needs to be done as simple as possible so that our guys can focus on the skills they need to do their job - not operate the radio.

 

[sarguy1941]

I wouldn't take my NEXT on any disaster comms type assignments. I'll have my 8000 and my laptop. To many places with no LTE and being you can't add wifi networks in the field I wouldn't be able to update. A cache of 8000's would be ideal for me.

 

[TRS]

I'm not impressed by:
-Having to use a cloud based service that sends all my codeplugs (including crypto keys) to a third party (most likely off shore) to be "authored" that takes time
-Paying a yearly SAS fee to do it
-Paying 8K-13K per subscriber

No thanks. HEY Harris, JVC Kenwood, Tait, Relm...whatcha got?

More than likely something similar in the pipe line to compete with it.

 

[crazyboy]

What keys are you sending ? I loaded mine with my KVL after programming before it would work.

Software keys also exist.

 

[sarguy1941]

True. I dont like software keys unless I have to. Too easy to leak out imho

 

[TESTMODE]

Non tethered programming is a deal breaker for me as far as comms disaster response. Give me a cache of 8000's with softkeys enabled and ASK owned any day of the year.

Our executive staff, especially those that live out of the system coverage area, will likely see the Next, but ops will never see it. We give them 1.5's with VA for a good reason; the less UI to deal with, the better. Not to mention the fact that they break the top display and controls left and right on the XE's as it is.

 

[Navy_BOFH]

I will try to get some more information for y'all - but I think there are some misconceptions as to how the NEXT will be programmed and maintained. For one - there is infrastructure software to be loaded onto the Master Core of a system to handle programming and maintenance of the radios. I have seen the software but have not worked with it yet - it is part of a future training week that is planned. But the Engineers I have talked to said it will be "just another piece of sotware offered to the customer to be loaded on the core like WAVE or RM"... in the sense that you will own the instance in your own network.

Motorola has servers for this stuff right now and is "cloud based" - but that is mostly for these demos. I think there is a possibility of cloud-based services for smaller accounts... but the instances I am referring to are for large customers with HEAVY FIPS and audit requirements with IA teams that will not allow these apps to be run anywhere outside of their own network... and they're wanting the NEXT as well.

All I can say is "stay tuned".

 

[MTS2000DES]

I'd be curious to know how "infrastructure software" loaded on my core will handle codeplugs with system keys (software and hardware) of OTHER systems that are NOT associated with my system. There are too many questions about this product platform, and at a premium price, it is hard to go before a governing body and ask for money for "unknown" expenses. In the meantime, until factual documentation is available from MSI on the self-maintenance or SAS options, we'll keep ordering APX6000/8000s. Should they become discontinued, we will evaluate other vendors' options for subscriber radios that are of "like, kind and quality" so that our taxpayers are not throwing money we don't have down a black hole.

 

[PSEhub]

In 10-15 years, do you really expect your APX NEXT with an SDM660-2 from 2017 to still support an Android version that can get security patches, and continue to work fully on AT&Ts network?

You are already starting off with a 2017 Qualcomm product, that won't be supported much longer, meaning no security patches.

Do you really expect that Motorola will keep an agreement going with Qualcomm to continue patching for the SDM660 for 10+ years?

Smartphones become outdated much more quickly than radios. To combine them into a single device doesn't make sense

Many of the very reasons people use dedicated radios with a dedicated infrastructure in the first place are entirely negated by the NEXT. It just doesn't make sense