• 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.

HAMS: Beware of DMR-MARC codeplug templates/cloning

Status

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
5,072
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 shit overwrote the new shit).

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

Contributing Member
CS Forums $upporter
Joined
Feb 27, 2015
Messages
59
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

Prolific Contributor
CS Forums $upporter
Joined
Jan 18, 2013
Messages
2,908
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

Prolific Contributor
CS Forums $upporter
Joined
Jan 18, 2013
Messages
2,908
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.
View attachment 9871

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.
 
OP
Mars

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
5,072
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.
 
OP
Mars

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
5,072
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.
View attachment 9871
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

Contributing Member
Joined
Feb 5, 2016
Messages
29
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.
 
S

syntrx

Not Registered
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

Prolific Contributor
CS Forums $upporter
Joined
Jan 18, 2013
Messages
2,908
That's why they are called "Sample Codeplugs" LOL!
 

Gtaman

Prolific Contributor
CS Forums $upporter
Joined
Apr 27, 2013
Messages
346
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.
 
OP
Mars

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
5,072
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 shit 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.

:drunk:
 
Status