Up one level (GTX index) Up two levels (Moto index) Back to Home

Model Definition File (MDF) Secrets By Robert W. Meister WA1MIK

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:

Decimal	15	14	13	12	11	10	9	8
Hexadecimal	F	E	D	C	B	A	9	8
Binary	1111	1110	1101	1100	1011	1010	1001	1000

Decimal	7	6	5	4	3	2	1	0
Hexadecimal	7	6	5	4	3	2	1	0
Binary	0111	0110	0101	0100	0011	0010	0001	0000

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:

Offset	Length	Description
0	4	Starting offset of section
4	2	Length of an entry in the section
6	2	Number 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:

Offset	Length	Description
0	8	Header for section 1
8	8	Header for section 2
10	8	Header for section 3
18	8	Header for section 4
20	8	Header for section 5
28	a	Data for section 1
a+28	b	Data for section 2
a+b+28	c	Data for section 3
a+b+c+28	d	Data for section 4
a+b+c+d+28	e	Data 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:

Offset	Bytes	Reversed	Decimal	Description
00	28000000	00000028	40	Offset of section 1
04	0E00	000E	14	Length of section 1 entries
06	1E00	001E	30	Number of section 1 entries
08	CC010000	000001CC	460	Offset of section 2
0C	0E00	000E	14	Length of section 2 entries
0E	0400	0004	4	Number of section 2 entries
10	04020000	00000204	516	Offset of section 3
14	0E00	000E	14	Length of section 3 entries
16	0E00	000E	14	Number of section 3 entries
18	C8020000	000002C8	712	Offset of section 4
1C	1000	0010	16	Length of section 4 entries
1E	1300	0013	19	Number of section 4 entries
20	F8030000	000003F8	1016	Offset of section 5
24	3200	0032	50	Length of section 5 entries
26	1400	0014	20	Number 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:

Offset	Description
00	Radio Low Limit
02	Radio High Limit
04	Transmit Low Limit
06	Transmit High Limit
08	Receive Low Limit
0A	Receive High Limit
0C	Index 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:

Offset	Bytes	Reversed	Decimal (MHz)	Description
00	0023	2300	8960 (896.0)	Radio Low Limit
02	C224	24C2	9410 (941.0)	Radio High Limit
04	0023	2300	8960 (896.0)	Transmit Low Limit
06	3C23	233C	9020 (902.0)	Transmit High Limit
08	8624	2486	9350 (935.0)	Receive Low Limit
0A	C224	24C2	9410 (941.0)	Receive High Limit
0C	0A00	000A	10	Index value

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

This short text file explains the step-by-step modifications to a GTX.MDF file to allow the radio to operate in the 896-904 and 926-941 MHz bands.

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.

Offset	Value	Description
00	1C
01	7A
02	68
03	19
04	47
05	E1
06	00
07	02
08	4D	Model Number Character - M
09	31	Model Number Character - 1
0A	31	Model Number Character - 1
0B	57	Model Number Character - W
0C	47	Model Number Character - G
0D	44	Model Number Character - D
0E	34	Model Number Character - 4
0F	43	Model Number Character - C
10	42	Model Number Character - B
11	31	Model Number Character - 1
12	5F	Model Number Character - _
13	4E	Model Number Character - N
14	0A	Band Entry Index (09=800 MHz, 0A=900 MHz)
15	0F	Features/Options Index
16	0C	TX Power (03=3w, 0C=12w, 1E=30w, 23=35w)
17	0A	Number of conventional modes (10 decimal)
18	0A	Number of systems (10 decimal)
19	08	Number of subfleets (8 decimal)
1A	0A
1B	64
1C	00
1D	43
1E	FE
1F	0C
20	41
21	4C
22	09
23	5F
24	4C
25	08
26	80
27	08
28	08
29	00
2A	30
2B	00
2C	02
2D	00
2E	00
2F	00
30	00
31	00

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.