Up one level (GTX index)
Up two levels (Moto index)
Back to Home
  Model Definition File
(MDF) Secrets

By Robert W. Meister WA1MIK
  Print this Page


Several Motorola radio software packages deal with multiple model numbers. To make the program more general, a Model Definition File (a data file with an MDF extension), is used by some programs to store specific information; thus Motorola doesn't need to maintain many unique programs for model series that have dozens of variations. For example, one program handles all trunked MaxTracs, while another handles all conventional MaxTracs. This article will describe some of the sections of this file that you, as an amateur radio operator, may find useful. I have used the GTX.MDF file from the GTX software package RVN4150 Version R04.00.01a (dated 06-Oct-00) in the examples below.

Background:

Radio series whose programming packages use MDFs include GM300, GTX, MaxTrac, and probably several others. My personal history includes these particular models. There are well over one hundred packages; some use MDFs, many do not. These packages usually need to be modified to allow radios to be programmed into the amateur frequencies and to increase the conventional channel capacity, on those models that can do trunking as well as conventional. Almost all commercial radio shops will have their own copies of the specific programming package, but very few will modify it for either of the above purposes. You can ask, but be prepared for the laughs. Naturally, Motorola does not support such modified software, nor do they want people to be aware it's even possible.

Hexadecimal Numbering:

All of the values shown in this article are in hexadecimal. This gives us 16 unique values that describe four bits. Two such values are used to represent each eight-bit byte. The possible values for each four-bit quantity are shown in the table below:

Decimal15141312 111098
HexadecimalFEDC BA98
Binary1111111011011100 1011101010011000

Decimal7654 3210
Hexadecimal7654 3210
Binary0111011001010100 0011001000010000

Values in one eight-bit byte can range from 0 to 255 (decimal), 00-FF (hexadecimal), or 00000000 to 11111111 (binary). Throughout the rest of this article, values will be shown in hexadecimal unless otherwise noted.

Things get complicated when we look at groups of bytes in the MDF using a hex editor. The bytes seem to be organized backwards, making it difficult to read them on the screen. For example, if you saw two bytes together written as "1234", you might assume that the value really is 1234, but in reality, the first byte that the computer sees is "12" and the second byte is "34", and it organizes these in the reverse order internally as "3412". You need to remember this whenever you make changes to the MDF. The hex editor can be told to flip the byte order around when it tries to make sense out of multiple byte quantities; a setting called "Little Endian" needs to be enabled to make this work properly. Intel-based computers (which the programming software operates on) are Little Endian and the data in the MDF is in the same byte order.

So what does this mean to us? If you're looking for a value of 8960 (decimal), you would convert this to 2300 and search for it, but you probably wouldn't find it. You need to flip the bytes around end-for-end, and actually search for 0023. This is how it's represented in the MDF. Most hex editors can make all of these conversions for you, if they are configured properly.

Four-byte quantities are also flipped around, but in addition to flipping each byte in each pair of bytes, you also must flip the two pairs around. For example, a four-byte quantity that represents an offset within an MDF might be 12345678. This would be displayed as two values "1234" and "5678". By flipping everything around, the correct offset value that you'd see on the screen is actually 78563412. Luckily these offsets are usually fairly small, and the second half of the four-byte quantity is often 0000, so you only need to work with the first two bytes and flip those around. A real-life example offset would be 28, which is represented in the MDF as 2800 0000.

All of this can be confusing at first, but you get used to it and let the hex editor do most of the work. You will need to remember this and switch bytes yourself if you're going to be modifying the MDF. Little Endian means you would enter the low eight-bits first, followed by the more significant eight-bits.

If you need to convert decimal to hex or vice versa, you will find that the Windows Calculator will do it for you. Just start up the calculator (Start -> Accessories -> Calculator) and click on "View" and select "Scientific". Then select your mode with the radio buttons on the top left, type in your number, and select the other mode. For example to translate hex 10E2 to decimal just select Hex, type in 10E2 and select Dec. Bingo - you see 4322. The binary conversion works in a similar fashion.

Speaking of hex editors, the one I use is called Hex Workshop by BPSoft. A hex/decimal calculator is provided with this product too.

Words To The Wise:

Before you modify any file, make one or two backup copies. Put them in another folder or even on a floppy disk so you can't change them accidentally.

Also, always make a checksum of the data in the file and write it down somewhere. Usually this will be a 16-bit checksum for MDFs. With Hex Workshop, choose Tools from the top-line menu, then Generate Checksum; select Checksum (16-bit) and On Entire File, then click Generate. On my file, the checksum value is 73F0. If you make any modifications to data in the MDF, you must change some other unimportant bytes by an appropriate amount so the checksum value is maintained. Failure to do so will render the software package unusable. This is not necessarily an easy process, but if you increase the value of one byte, you must decrease the value of another byte to compensate. Good candidates for modification are unused model number strings and the 800 MHz frequency entries.

The Checksum-16 method of validating a data file simply adds up every byte in the file and then adds two more bytes (reserved for this purpose) to make the grand total come out to zero (or some other unique value that the program knows about). If you can identify these two bytes (often they're at the end of the file) you can modify them so the checksum value of the whole file remains constant. There seems to be two such bytes at the end of the GTX MDF, but modifying these in an attempt to fix the checksum still causes the program to fail, so you must modify other unimportant bytes in the MDF to restore the checksum value.

General File Layout:

The MDF begins with a header section that's similar to a table of contents in a book. Reading these first few bytes lets you find your way to other sections of the file. These sections follow the header, just as the chapters in a book follow its table of contents. The sizes of the header, the number of sections, and the size of each section are variable; the size information is found in the header. The trailer is not present in all MDFs. For a typical MDF, here's what we have so far:

Header
Section 1
Section 2
Section 3
Section 4
Section 5
Trailer

File Header Layout:

Each entry in the header is eight bytes long and is laid out as follows:

OffsetLengthDescription
04Starting offset of section
42Length of an entry in the section
62Number of entries in the section

The first value in the table is a four-byte quantity that has the starting offset of the section in the MDF that this entry refers to. As each header entry occupies eight bytes, if there are five entries, the entire header occupies 40 (decimal) bytes, and the offset of the first section would be 40 (decimal) or 28 hex. For an MDF with five sections, the file would be arranged like this:

OffsetLengthDescription
08Header for section 1
88Header for section 2
108Header for section 3
188Header for section 4
208Header for section 5
28aData for section 1
a+28bData for section 2
a+b+28cData for section 3
a+b+c+28dData for section 4
a+b+c+d+28eData for section 5
a+b+c+d+e+28?Possible trailer

The length of each section is the product of the length of each entry times the number of entries. We don't really need the starting offsets of each section, but they do make access quicker. Here's the header from the GTX MDF file, shown as individual single-byte quantities:

28 00 00 00 0E 00 1E 00
CC 01 00 00 0E 00 04 00
04 02 00 00 0E 00 0E 00
C8 02 00 00 10 00 13 00
F8 03 00 00 32 00 14 00

If these are grouped into four- and two-byte values, then reversed and converted to decimal values, they begin to make a whole lot more sense:

OffsetBytesReversedDecimalDescription
00280000000000002840Offset of section 1
040E00000E14Length of section 1 entries
061E00001E30Number of section 1 entries
08CC010000000001CC460Offset of section 2
0C0E00000E14Length of section 2 entries
0E040000044Number of section 2 entries
100402000000000204516Offset of section 3
140E00000E14Length of section 3 entries
160E00000E14Number of section 3 entries
18C8020000000002C8712Offset of section 4
1C1000001016Length of section 4 entries
1E1300001319Number of section 4 entries
20F8030000000003F81016Offset of section 5
243200003250Length of section 5 entries
261400001420Number of section 5 entries

The first section begins at offset 28, and the header ends just before that.

So, now we know where each section begins and how big it is. This is crucial to locating the list of valid frequencies and model numbers, although you could hunt around and probably find some of this if you were bored.

Section 1:

So, now what do we do with all of this information? From what I've observed, several sections are always present, and Section 1 is one of them. It contains model option and capability strings that show up on the screen when you're initializing a radio. Not all of these would be used on every radio series; the GTX MDF file contains information that's obviously not intended for a GTX radio (i.e. Radius Trunked).

From the index, we know that each entry is 14 (decimal) bytes long and there are 30 entries in the list. Other than looking at the interesting strings you find here, these don't require modification for ham use. However some bytes herein could be changed to straighten out the checksum.

Section 2:

This section contains the radio series strings, again used mainly during radio initialization or to display the proper model number in the software. Also not interesting, but you should leave them alone.

Section 3:

This is one section you DO want to get intimate with, as it contains the list of frequency ranges that the software and radio know about.

Each entry in this section is 14 (decimal) bytes long. This leaves room for seven two-byte quantities. The frequencies themselves occupy two bytes each and form a value in 0.1 MHz increments. For example, the value 1508 (decimal) represents 150.8 MHz. You won't see the decimal point but it is implied. Similarly, 896.0 MHz would be saved in the file as 8960 (decimal).

There are three frequency range pairs; each consists of a lower and upper frequency limit for the radio itself (or the FCC limits), the transmitter, and the receiver. One last two-byte value is an index number that is used elsewhere. So, each entry in this table is laid out as follows:

OffsetDescription
00Radio Low Limit
02Radio High Limit
04Transmit Low Limit
06Transmit High Limit
08Receive Low Limit
0AReceive High Limit
0CIndex value

The Radio Limits are what the radio (hardware) and programming package (software) will limit you to. These are probably what the FCC type acceptance limits the radio to as well. For VHF and UHF radios, the transmit and receive limits will have the same values.

Some packages let you use the SHIFT-NUM method of entering out-of-range frequencies: hold down the SHIFT key while entering the numeric characters. For example, to enter 927.41250 MHz, hold down SHIFT and press the 927 keys, then release SHIFT and press the period key, then hold down SHIFT again and press the 41250 keys. You must enter all the digits to fill the field, including trailing zeroes. When you finish, the field will look like this (without the quotes): "(@&.$!@%)"

The GTX product line, and therefore the MDF file, contains both 800 MHz and 900 MHz radios. Here's the frequency limit data for the 900 MHz radios, at offset 0290, grouped into two-byte values:

0023 C224 0023 3C23 8624 C224 0A00

Applying the above layout, we get the following information:

OffsetBytesReversedDecimal (MHz)Description
00002323008960 (896.0)Radio Low Limit
02C22424C29410 (941.0)Radio High Limit
04002323008960 (896.0)Transmit Low Limit
063C23233C9020 (902.0)Transmit High Limit
08862424869350 (935.0)Receive Low Limit
0AC22424C29410 (941.0)Receive High Limit
0C0A00000A10Index value

The index value is used in the Model Information section entries, described below.

Sections After 3 and Before The Last One:

These sections contain some information that's used when the radio is initialized or the code plug is being written out. Some MDFs have only one section here while others have more. The information in the header will tell you where each section starts and how many of them there are.

Last Section:

This section contains the model information entries: things like model numbers, transmitter output power, number of trunked systems, number of trunked talk-groups, number of conventional modes, frequency band index, etc. The layout of this table varies with the software package, unfortunately. The model number string always has an underscore in the 11th character position; this is usually where a model revision letter is present on the radio's sticker.

In the GTX MDF, the bytes after the model number seem to have the following meanings. This is the second model descriptor entry at address 042A.

OffsetValueDescription
001C 
017A 
0268 
0319 
0447 
05E1 
0600 
0702 
084DModel Number Character - M
0931Model Number Character - 1
0A31Model Number Character - 1
0B57Model Number Character - W
0C47Model Number Character - G
0D44Model Number Character - D
0E34Model Number Character - 4
0F43Model Number Character - C
1042Model Number Character - B
1131Model Number Character - 1
125FModel Number Character - _
134EModel Number Character - N
140ABand Entry Index (09=800 MHz, 0A=900 MHz)
150FFeatures/Options Index
160CTX Power (03=3w, 0C=12w, 1E=30w, 23=35w)
170ANumber of conventional modes (10 decimal)
180ANumber of systems (10 decimal)
1908Number of subfleets (8 decimal)
1A0A 
1B64 
1C00 
1D43 
1EFE 
1F0C 
2041 
214C 
2209 
235F 
244C 
2508 
2680 
2708 
2808 
2900 
2A30 
2B00 
2C02 
2D00 
2E00 
2F00 
3000 
3100 

You can change the number of modes (channels) on GTX portables and mobiles, but you won't get very far if you change the band index or power range. In other words, you can't turn an 800 MHz GTX radio into a 900 MHz GTX radio by changing the byte at offset 14 from 09 to 0A. Also, if you are trying to program a radio that was previously programmed with modified software and has more than the stock number of modes programmed into it, you'll have to modify your MDF file appropriately so the software will read the radio. Without making that change the software will complain and not let you do anything with the radio's code plug.

Some of the bytes in the entry are indexes into things like the frequency range table, the initialization byte table, the product line, the model series, etc.

Trailer:

The trailer, if present, would start right after the last section. In our example, the last section starts at offset 1016 (decimal) and contains 20 (decimal) entries of 50 (decimal) bytes each; therefore the last section ends at offset 2015 (decimal) and the trailer starts at offset 2016 (decimal). The GTX MDF contains an eight byte trailer that seem to be a revision number and a checksum; add these to the bytes already accounted for, and you get the total length of the file: 2024 (decimal) bytes exactly. I love it when a plan comes together!

Other Caveats:

If you patch an MDF to let you program amateur frequencies or add more modes, and use this package to write a code plug to a radio, you may find that if you then use stock software to make additional changes to the radio, the software will un-do some or all of your changes. For example, using patched software to extend a 16-channel MaxTrac to 32 channels will work fine as long as you continue to use that same patched software when working on that radio. But if you subsequently read the radio with stock software and make changes to the code plug, only 16 channels will be written back to the radio. It would be better to change the radio's model number (with lab software) to turn it into one that has the features (such as number of modes) you want. This way, all of the stock software will still work with future radios you may encounter and you won't need to carry that patched file around with you.

Contact Information:

The author can be contacted at: his-callsign [ at ] comcast [ dot ] net.


Back to the top of the page
Up one level (GTX index)
Up two levels (Moto index)
Back to Home

This article first posted 18-Nov-2007


Hand-coded HTML © Copyright 2007 by Robert W. Meister WA1MIK.

This web page, this web site, the information presented in and on its pages and in these modifications and conversions is © Copyrighted 1995 and (date of last update) by Kevin Custer W3KKC and multiple originating authors.   All Rights Reserved, including that of paper and web publication elsewhere.