HAMS: Beware of DMR-MARC codeplug templates/cloning

[Mars]

Hamsters: You need to be aware of a complication/undesirable issue which will manifest itself if you choose to use/clone a DMR-MARC codeplug template into your radio.

Example: If you are using a R02.50.05 (firmware) R09.04.22 (codeplug) radio, and you try dumping/cloning programming from another TRBO radio with the same model/tanapa into yours, be sure to check the codeplug versions match.

I'm working on a support issue for a client which involves missing features/unfavorable audio settings. His codeplug was at R09.04.22 and firmware was R02.50.05 (latest versions). After investigating the complaints, it was discovered values/settings from an older codeplug version were present, which wiped the internal values out, associated with those found in a R09.04.22 template. (old **** overwrote the new ****).

Be sure to verify the codeplug versions match (not CPS versions; codeplug versions) before doing a direct clone. A drag-and-drop of pertinent data is safe, and should be done instead of a direct codeplug clone.

Should anyone be affected by this complication, the only option is to perform a recovery option, from within CPS. Be sure to back up your tuning file before committing to this repair.

[Cacciatore]

Should anyone be affected by this complication, the only option is to perform a recovery option, from within CPS. Be sure to back up your tuning file before committing to this repair.

So does the Recovery Option actually wipe the tuning data or not? Motorola support informed me that the tuning values were not touched, but I have more faith in you, Mars than the intern that I was likely talking to.
CPSwarning.PNG

[com501]

Are you saying that CPS will allow an overwrite of a codeplug written (with older firmware) to a radio with 2.50.05/ with 11.2 CPS without any warning?

[com501]

So does the Recovery Option actually wipe the tuning data or not? Motorola support informed me that the tuning values were not touched, but I have more faith in you, Mars than the intern that I was likely talking to.
CPSwarning.PNG

Simple test.

Read your radio with Tuner.

Save it.

Open Tuner, jot down some prominent settings.

Recover the radio.

Look at those parameters again for comparison.

I'll bet they are defaulted.

[Mars]

I may be confusing people. Do not pay attention to the firmware version, but rather the codeplug version. The current codeplug version posted above, has all of my audio refinements and those included from Motorola. The code plug file is an encrypted XML configuration profile.

There are definitions and values for various items. Some definitions/values are not accessible through the CPS GUI interface. They are hidden.

When you clone a codeplug with an older codeplug version into a newer codeplug version, the newer values are overwritten with those from the source codeplug.

The codeplug I worked on this afternoon, which was the latest version, had old values in the XML data, that were placed there through a cloning operation where the source file was older.

This is the fault of Motorola's sloppy coding. There are additional XML definitions which determine behavior during cloning or firmware upgrades. This also applies to CPS read and write operations.

Short version: this is a bug. Anyone cloning codeplugs should pay close attention to the version numbers.

[Mars]

So does the Recovery Option actually wipe the tuning data or not? Motorola support informed me that the tuning values were not touched, but I have more faith in you, Mars than the intern that I was likely talking to.
CPSwarning.PNG

If your radio goes into flashzap mode during the recovery process, your tuning partition will absolutely be wiped out.

It is always good practice to have your current tuning file backed up in at least one location.

[alice715]

I've made multiple recovery experiment and so far none of them wiped the tuning partition.
However, it is a good practice to always have a backup of the tuning partition. Otherwise, you would have to spend time to get it re-tuned or even if you can find a place that does it.

It may not happen but hey, sht happens.

[syntrx]

Same applies for the example codeplugs that come with CPS, which are derived from radios with early development firmware.

Before my first TRBO radio was delivered many years ago, I thought I'd be really clever and write all of my frequencies into using one of the example codeplugs that comes with CPS, thinking I could just clone it into my new radio as soon as the FedEx guy arrived be up and running straight away.

Yeah, nah. Don't do that. Menu options disappeared and all sorts of other weird things happened.

[com501]

That's why they are called "Sample Codeplugs" LOL!

[Gtaman]

SHIFT! I just did that today. With an XPR 6550. Never thought it would be a problem. Better go back to its orginal code plug.

[Mars]

Just had a user on our LCP trunking network jam up the whole system (unintentionally) because he put a R02.50.04 firmware codeplug template into a radio he had just updated to R02.50.05. .04 obviously has the major LCP bug/issues.

He didn't know any better. Thanks for completely ****ing things up, Motorola.

If you don't want to fix these cloning issues, at least enforce a rule that prohibits a user from writing an older codeplug template to a radio with new(er) template version. That way people don't go backwards/delete the XML changes/revisions which are paired with specific firmware releases.

To make things worse, users with firmware such as R02.50.05, are unable to refresh to the same version, again. This would fix the issue with the codeplug templates being out-of-whack, without having to do a restore and lose all codeplug programming parameters. What's the recommendation, Motorola? Clone the **** R02.50.04 codeplug back into the radio again, after restoring to R02.50.05 and repeat the problem?

I told this specific guy to use depot to force a R02.50.04 package back to his radio, dump the codeplug back in, then use CPS to do a firmware update to R02.50.05. That's the only way to preserve the programming. Thanks for leaking Depot tool; it actually helped this fellow save countless hours he would've otherwise had to waste redoing his codeplug again.