Information Common to Both Maxtrac and Radius

Information Common to Both Maxtrac and Radius
Since these radios are so much alike, lets start with some things you can do that apply to both series of radios.

Codeplug Checksum Location
If you happen to be messing around in the codeplug file, be aware that the first 0x2D bytes need to have the proper checksum (stored at offset 0x2E).
For example, if you wanted to calculate the checksum of the following header in a codeplug file:

You would select the bytes and do a 1's Complement Hex Checksum calculation.


The Checksum-8 value is the one you want to enter into offset 0x2E. In this case you can see that they already match.
We've been told that the same applies if you are changing the serial number of the radio using the EEPROM access feature of Lab RSS. The nice feature of using the Lab RSS is that it has the option to correct the checksum for you.


Location of Model Index in Codeplug
First, lets take a look at an example from a .mdf file:

The highlighted entry contains all the info for a specific model of radio.
For the particular model selected, the index that refers to this radio is this:

Now, if you open the saved file (codeplug) for your radio, you'll see something like this at the beginning of the file:

Now, the tricky part of this is, the index isn't stored in one location. The red bytes are the index. Notice they match the index bytes you found in the .mdf file.

The significance of knowing the index number for your radio comes to when you start modifying the .mdf file for specific features in your model of radio. If you were to search for your model number in the .mdf file, you will have more than one hit, but, they each have unique index numbers...
Add Channels by Editing the .MDF File
This information is common to both the Maxtrac and Radius lines. Depending on which logic board and firmware is in your radio, this may or may not work. The example screenshots shown are for the Maxtrac version R06.01.00c RSS.
Open the MAXTRAC.MDF or RADMBL.MDF in your Hex editor, Hex Workshop is an excellent program for this. The Maxtrac and Radius RSS don't do any checksum checks of the file so you don't have to worry about correcting the checksum later.
Search for your model number in the file, you probably will come accross more than one entry so you can either change them all or use the information above to locate the proper index to change a specific model.
Once you find your model entry you should see something like this:

If you look at this model entry, the third byte after the model number (offset 0x1036) is a 0x20.

This is the hex representation for the number of channels in the radio, in this case 32 ch. Depending on your radio you might want to try changing this to 0x10, 0x20, or 0x28, or higher to give you 16, 32, and 40 channels respectively.
Also note the 0x02 at offset 0x1034, this is the bandsplit identifier for this radio and corresponds to the table entry at the top of the .mdf file.
The 0x01 at offset 0x1035 refers to the power level of the radio.
To find out if you picked the correct model number to edit, save the .mdf file and load your radio's codeplug into the RSS. Try adding channels with the Mode Utility and see what happens.
One thing you have to be careful of is that the RSS will let you put as many channels into it that you want, what the radio will accept is another thing. It appears that once you exceed the maximum number of channels for a radio and try to program them in, the firmware will "wrap" the extra data around to the beginning and start programming from channel 01. You will be able to tell if you have exceeded the maximum number of channels by trying to program in one channel at a time until it "wraps", ie. if the maximum number of channels your radio will take is 16 and you try to program 17 channels into it, once programming has finished you will find your radio will only show 1 channel. Another thing that might happen is that if you exceed the number of channels programmed into the radio, the display will show funny things as you scroll through the channels, it depends on the firmware in the radio.
.MDF File Structure
OK, we have finally figured out most of the information contained in a record in the .mdf file for the Maxtrac/Radius line.
By knowing this, we are able to do things like enable scan, signalling, etc. However, even if you enable the options by editing the .mdf file, it does not mean that they will always work, the firmware in the radio has to support the options as well.
Now, on to the structure itself. The highlighted area below indicates an individual record for a particular model Maxtrac. The Radius is essentially the same, just with different model numbers.

As you can see, this example covers a model located between offsets 0x01BB6 and 0x01BCA inclusive. The breakdown of the record is as follows:
Offset (example)Description
0x1BB6-0x1BB7Model Index
0x1BB8Displayed Model Name
0x1BB9-0x1BC4Model Number
0x1BC5Bandsplit Index
0x1BC6Radio Power Level
0x1BC7Number of Channels
0x1BC8Displayed Power
0x1BC9-0x1BCARadio Options
Field descriptions:
Model Index
As can be seen elsewhere on this page, the Model Index is what actually tells the RSS what radio you are working with. It figures out the index from the codeplug in the radio or on file and locates the appropriate record in the .mdf file based on that information.
Once the RSS knows the Model Index, it can read all the specific information on what that radio is capable of by reading the rest of the model information in the .mdf file record.
Displayed Model Name
This byte determines what model name (ie. Maxtrac 300, Radius M214/216) is displayed in the RSS when you read the radio codeplug.
All the possible model names are stored at the beginning of the .mdf file. If you change this byte, the model name displayed will change. For example, this radio has a byte of 0x07. If you read this radio, it will have a name of Maxtrac 300. If you change the byte to 0x06, the name will change to Maxtrac 100.
Model Number
These bytes are the hex representation of the actual model number of the radio in question. That's about it. There are a number of radios in the Maxtrac/Radius series that have the exact same model number, but have different features or options. That is why there is no model breakdown chart for them. The only way to actually figure out the options in a particular radio is to read it.
Bandsplit Index
This byte determines which bandsplit information record is used for this radio. The bandsplit table is located just under the model names at the beginning of the .mdf file. More information on the structure of that table is available elsewhere on this page.
Radio Power Level
Not exactly sure on how this one works. It depends on what the bandsplit of the radio is and the power level (high or low).
Number of Channels
This byte is a hex representation of the number of channels in the radio. It is explained further elsewhere on this page.
Displayed Power
This byte is a hex representation of the power level of the radio. It is used to display the power level on the Radio Wide screen. By changing this byte, you will change the power field on the Radio Wide screen. It has no other effect.
Radio Options
These two bytes are some of the most important. They determine what options are enabled in the radio and are capable of being modified by the RSS. Now, just because you enable the options, it doesn't mean that your radio will support them, that depends on the firmware in the radio, as well as the codeplug in the radio. It is generally possible to upgrade the firmware in the radio, and usually will involve blanking, re-initializing, and re-tuning the radio in the process, but it is possible.
It also appears that some options need to be turned on in the codeplug of the radio, regardless of whether those bits are enabled in the .mdf file. The bytes in the radio that seem to affect these options are at offset 0x1FE and 0x1FF in a codeplug archive.
At any rate, what we have determined from the .mdf file is as follows...
Options are determined by whether a specific bit in the option bytes are turned on or off. Each of the two option bytes can be broken down into an upper nibble, and a lower nibble. When each nibble is converted to binary, you get all the possible option bits that can be changed.
In this example, our option bytes are the fairly common 0x27, 0x1C. This translates as follows:
          NAME     UPPER1       LOWER1       UPPER2       LOWER2
          HEX         2            7            1            C
          BIN      0 0 1 0      0 1 1 1      0 0 0 1      1 1 0 0
          BIT#     4 3 2 1      4 3 2 1      4 3 2 1      4 3 2 1
If we look at the UPPER1 nibble, bits 1 through 4 correspond to the following options when set (1):
          BIT#     DESCRIPTION
          1        Unknown, causes a ERROR #56 if set
          2        Enables Emergency Alarm and Signalling (MDC1200/STAR/QCII/DTMF)
          3        Unknown
          4        Unknown
If we look at the LOWER1 nibble, bits 1 through 4 correspond to the following options when set (1):
          BIT#     DESCRIPTION
          1        TPL/DPL/INV DPL/CSQ Squelch, Squelch field under Radio Wide set to CODED
          2        TPL/DPL/INV DPL/CSQ Squelch, Squelch field under Radio Wide set to CARRIER
          3        Enables Scan
          4        Unknown
Note, if you do not set either bit 1 or 2 of LOWER1, then the only squelch option you are allowed in a Maxtrac is INV DPL, and in a Radius, CSQ. Normally both bits 1 and 2 are always set.
If we look at the UPPER2 nibble, bits 1 through 4 correspond to the following options when set (1):
          BIT#      DESCRIPTION
          1         Enables Accessory Connector (if supported by radio)
          2         Unknown
          3         Unknown
          4         Unknown
If we look at the LOWER2 nibble, bits 1 through 4 correspond to the following options when set (1):
          BIT#      DESCRIPTION
          1         Unknown
          2         Unknown
          3         Affects TOT, base frequency, and signalling options, must be set
          4         Enable Call List (used in conjunction with UPPER1, BIT#2
To determine what to put in the .mdf file in the option bit locations, figure out what bits you want set, convert the binary representation of the nibble to hex, and stuff it in the proper location in the .mdf. In general, if you want to enable scan and signalling (if supported by your radio), use the option bytes in this example (0x27, 0x1C).

No comments:

Post a Comment

Thanks for your comments, Comments may take a day to show up

Used for discussions, it is a collaboration group

Digital Ham Radio / Amateur Radio
https://groups.io/g/DigitalHamRADIO

Amateur Radio Users Support Group
https://groups.io/g/AmateurRadio

North America Amateur Frequencies
https://groups.io/g/Frequency
.