All the values and addresses may be slightly different in your file.

The GTX.MDF file that was sent to me is 2,024 bytes long.

Addresses and data bytes (shown as comma-separated pairs) are HEX values.

The 16-bit checksum of the whole file is 73C8. It must still have this 
value when you've finished modifying the MDF file.

The entry for 900 MHz is at 000290: 896-941, 896-902, 935-941 MHz. Each 
frequency entry has low and high limit pairs for the displayed band, the 
TX frequencies, and the RX frequencies.These values are in INTEL byte order, 
where the low-value byte comes first. Take for example 00,23 below: If you 
flip the bytes to 23,00 and enter these into the Windows Calculator in HEX 
mode, then select DECIMAL mode and it will show a decimal value of 8960, 
which is the frequency in 100 kHz steps.

You can use the Windows Calculator to convert a decimal value to a hex value 
to get the bytes you need to enter into the MDF file. Just remember to flip 
the two bytes around so the right-most byte in the Calculator is the left-most 
byte in the MDF file.

000290 = 00,23 = 8960
000292 = C2,24 = 9410 These are the band limits: 896-941 MHz, in 100 kHz steps.
Nothing gets changed here. These are still the bamd limits.

000294 = 00,23 = 8960
000296 = 3C,23 = 9020 These are the TX limits: 896-902 MHz.
Change 000296 from 3C,23 to 50,23 = 9040 to give yourself some extra room.

000298 = 86,24 = 9350
00029A = C2,24 = 9410 These are the RX and TX talk-around limits: 935-941 MHz.
Change 000298 from 86,24 to 2C,24 = 926.0 to give yourself some extra room.

After these changes, the checksum is 7382. To fix this, I usually modify some 
bytes up around 000180, where the model names are stored, Since this MDF file 
is for a GTX, there's no need to preserve the MaxTrac names, so they can be 
sacrificed. By changing one or two spaces (hex 20) to other values, we can get 
the checksum back to 73C8.

For our first attempt, change 000180 from 20 to 60 and see what happens. The 
checksum went from 7382 to 73C2. We're close, so add 6 more and try again:
change 000180 from 60 to 66 and see what happens. The checksum is now 73C8, 
which matches the original checksum. We're done. Save and exit.

Note that I could have also subtracted 7382 from 73C8 and gotten 46. Adding 
that value to one of the spaces (hex 20) produces the final value 66. We 
were just lucky that the changes only affected the low byte of the values 
that got changed.

I modified the file that was sent to me. It now has TX limits of 896-904 MHz 
and RX limits of 926-941 MHz, as shown below:

Frequency Range Table Entries BEFORE CHANGES
... some have been deleted ...
0274: Entry 08 ( 8): RSS:   0.0-  0.0, TX:   0.0-  0.0, RX:   0.0-  0.0
0282: Entry 09 ( 9): RSS: 806.0-866.0, TX: 806.0-821.0, RX: 851.0-866.0
0290: Entry 0A (10): RSS: 896.0-941.0, TX: 896.0-902.0, RX: 935.0-941.0 <<<<<<<<
029E: Entry 0B (11): RSS: 330.0-370.0, TX: 330.0-370.0, RX: 330.0-370.0
02AC: Entry 0C (12): RSS: 336.0-368.0, TX: 336.0-368.0, RX: 336.0-368.0
... some have been deleted ...
Checksum: 73C8

Frequency Range Table Entries AFTER CHANGES
... some have been deleted ...
0274: Entry 08 ( 8): RSS:   0.0-  0.0, TX:   0.0-  0.0, RX:   0.0-  0.0
0282: Entry 09 ( 9): RSS: 806.0-866.0, TX: 806.0-821.0, RX: 851.0-866.0
0290: Entry 0A (10): RSS: 896.0-941.0, TX: 896.0-904.0, RX: 926.0-941.0 <<<<<<<<
029E: Entry 0B (11): RSS: 330.0-370.0, TX: 330.0-370.0, RX: 330.0-370.0
02AC: Entry 0C (12): RSS: 336.0-368.0, TX: 336.0-368.0, RX: 336.0-368.0
... some have been deleted ...
Checksum: 73C8