Batboard

Hello all,

I have heard members refer to codeplug and s-recs, are they different or are they the same?

Thanks!

Well, to begin with, the term codeplug has become a generic description of the user programming that defines the specific frequency and other operational parameters for a radio.

The term codeplug derives from the days when fully synthesized (e.g. not crystalled or rock-bound) radios were first hitting the market. The programming information lived in a PROM of some type, and the way you programmed your radio was to load the CODE into the PROM using a burner, and then PLUG the PROM into the radio - hence, code-plug. Nowadays, of course, you talk to the ROM in the radio (which is usually flash as opposed to an EEPROM) directly with a computer, and it takes a matter of moments to re-write the codeplug.

So anyway... for a while there, although you could program the radio using your computer, the features that the radio was capable of (whether you used them or not) were immutably defined by the firmware in the radio, or were extended with physical add-on hardware. Because what the radio was capable of was not at all defined by the codeplug (remember that the codeplug just told the radio how to behave with what it could already do), the programming software could manipulate 100% of the data in the codeplug itself willy-nilly, and could even create a brand new codeplug from scratch. Some more common examples of this capability could be found in the RSS packages for the Syntor X 9000, and the analog Saber and Systems Saber lines.

Now we fast-forward a bit. Radio manufacturers got wise to the fact that it sucked that adding features to a radio either involved completely (and manually) replacing the firmware ROM, or bolting on yet another bit of hardware, and started using Flash ROMs as firmware storage devices in the radio. This meant that now the firmware itself could be upgraded with relative ease simply by plugging the radio into a computer - no more swapping EPROM chips and cursing all the while. It also meant that the bit of information that defined what features were enabled (on Motorola radios, commonly known as the Flashcode) was stored in the codeplug memory space, along with the codeplug itself.

This was great from the field tech's perspective, but it brought up one little problem. If the firmware is 100% responsible for defining the ENTIRE feature set of the radio, how does the manufacturer allow you access to only the features that you've paid for? Remember that before that was easy - the radio's base firmware allowed the base functions, but usually if you wanted a fancier option, it came at the cost of a bit of add-on hardware, or at the cost of a newer class of firmware (trunking vs conventional, for example), or simply at the cost of a more expensive radio (System Sabers, anyone?). These were all easy enough for Motorola to control - don't fork over the cash, we don't mail you your option. But in the new paradigm, what's to keep you from using the programming software to generate a new codeplug from scratch and enabling access to whatever damned features you damned well please? Hence, this ability went by the wayside.

However, from a paragraph or two previous, you may recall that the record of enabled features was embedded as part of the codeplug's memory space in the radio. Here's where we start to talk about SRecords. Normally, when editing the codeplug using RSS or CPS, you would not have access to change the features that were enabled - that information was essentially read-only - unless you'd forked over the cash to Motorola for the appropriate upgrade kit that would tell your programming software "it is OK to turn on this feature for evermore". So, what was the entheusiast to do?

The answer was to get your hands on a bit of software that would read from and write to the entire range of codeplug memory space in the radio, without conducting the checks normally carried out by RSS and CPS. The stuff to do this is commonly known as Lab software, and was supposed to only exist within Motorola, but invariably would leak out. This kind of special programming software would let you suck the guts of a radio's codeplug out, and then brute-force shove them into another radio, and in the beginning that's exactly what people did. This would allow you to take a donor radio with the features you wanted, and clone it into a destination radio of the same type, model and bandsplit. Only problem with this procedure is that EVERYTHING would get copied over - serial number, tuning data, etc.

At a more basic level, a SRecord is simply a way of storing raw binary data in pure ASCII text format. The format is well defined, and information is available both on the Batlabs main site and also at various places out there on the wild wild web. Suffice it to say that the SRecord format was one of the ways that Lab software could store the raw binary information you'd just sucked out of a radio.

To wrap up this sordid tale are a few more tasty tidbits. Originally, when this kind of feature definition/control came out, the programming software was still DOS based RSS, and the codeplugs (which were also called "archives") that normal RSS saved to disk were still exact binary representations of the codeplug memory space of the radio. As we've already discussed, normal RSS wouldn't let you take a codeplug from one radio and program it into another - it would notice that the serial number, and flashcode (and maybe even model number) didn't match and would barf up an error. That being said, Lab software could accept either a DOS RSS archive or a SRecord as imput to blast into a radio. That's why you'll see people here requesting either a DOS RSS archive or a SRecord for their various and sundry projects.

Hopefully this 5am shaggy dog story makes some sense and provides some enlightenment...

Reading through the archives, I see posts saying "be sure to make a backup of the s-rec". I remember a little bit about Motorola s-records from working on embedded systems. Is the only way to pull a s-record out (and restore it) via lab software? We'd also need a different cable, say on an Astro Saber, for the flash port?

jland138 wrote:Is the only way to pull a s-record out (and restore it) via lab software? We'd also need a different cable, say on an Astro Saber, for the flash port?

In theory, any software capable of issuing the appropriate command to the radio can read/write its codeplug data in SRecord format. In practice, yes, this is limited to Lab.

You use the same cable as you use to program, there's no flashing or bootstrapping of the radio involved. Remember, you're just reading and writing the contents of the codeplug memory space, which is separate from the host and DSP firmware memory spaces, so it's assumed that the radio's host is up and running when you make the request.

Great post! Nothing like a good old informative read - well done.