Ok, I've read through the Maxtrac mdf file mods referenced on the GTX page. It seemd pretty straight forward... but going through the GTX mdf, it looks completely different! The original mdf would not allow putting in the HAM freqs, of course, and a fellow was kind enough to send me his mdf that worked. But when I back to attempt to figure out the changes, in HexWorkshop... I am lost! The only differences in the two mdf files are at 0x08DA-0x08DD offset. The original contains '3C23 8624' and the mod'ed one contains 'C224 0023'. Decimal conversion gives me '15395 34340' in the original and '49700 00035' in the mod'ed one. Now, I am a bit dense sometimes, but I can't figure out how these entries relate to the band limits at all! The Maxtrac page on BatLab says the numbers are straight forward frequencies, but 153.950 Mhz and 343.400 Mhz changed to 497.000 Mhz and 350 khz doesn't make any sense to me. Does anyone know the layout of the GTX.mdf file and how I might be able to allow 12.5 khz steps on the radio? There is a repeater on 927.837 Mhz here, and I can't get the radio to take that freq. Anyway, thanks for any help.
P.S. - I think, unless I'm way off base again, the reference on the GTX page on BatLab should not point to the Maxtrac mods as they seem to be very different than what is needed for the GTX conversion.
GTX RSS Questions
Moderator: Queue Moderator
Hi,
You have the right locations - take a look at the bytes; think of them as 16-bit pairs, the first pair (3C 23 or C2 24)sets the upper limit on the transmitter (in rptr mode), the second sets the lower limit on the receiver. But they are read backwards, so calculate 3C 23 as 23 3C, which equals 9020! 24 C2= 9410 I think you can figure it out from there. You can use this "fix" for any other freq range these radios do, BTW.
On the freq you mention, 927.8375 should work fine - 927.837 is probably an error in the freq list you are using.
73 DE Hartley
You have the right locations - take a look at the bytes; think of them as 16-bit pairs, the first pair (3C 23 or C2 24)sets the upper limit on the transmitter (in rptr mode), the second sets the lower limit on the receiver. But they are read backwards, so calculate 3C 23 as 23 3C, which equals 9020! 24 C2= 9410 I think you can figure it out from there. You can use this "fix" for any other freq range these radios do, BTW.
On the freq you mention, 927.8375 should work fine - 927.837 is probably an error in the freq list you are using.
73 DE Hartley
Thanks for the tip!!Oops, I knew there was something else!!
In the original mdf, reading left to right, the entries are 9020 9350 (decimal-reversed) and the mod'ed one reads 9410 8960. So, the question is why the apparent reversed upper/lower in the two and why with the original one (902-935) a 927.xxxx freq was rejected. I think I am having trouble understanding the "language" in Motorola RSS files... but then again, this is my first adventure into Motorola for Ham use. I'm loving it!! Fantastic equipment!!
Thanks again!
In the original mdf, reading left to right, the entries are 9020 9350 (decimal-reversed) and the mod'ed one reads 9410 8960. So, the question is why the apparent reversed upper/lower in the two and why with the original one (902-935) a 927.xxxx freq was rejected. I think I am having trouble understanding the "language" in Motorola RSS files... but then again, this is my first adventure into Motorola for Ham use. I'm loving it!! Fantastic equipment!!
Thanks again!
Hi,
OK - there are a couple other numbers in there that we didn't look at, but since we don't have to change them, that's OK. They express the range as two separate ranges - in the "STOCK" version, the rptr transmit range is 896-902 >> so we change the top end to something higher, like 941 (higher than we need, but the number is already there as the top of the receive/talkaround TX range, so it is easy to use - no calculations!). The "stock" receive/talkaround range is 935-941, so we change the low end to something lower, like the 896 that is already the lower limit for the rptr TX range (look at the .mdf file & you will see them!). Naturally, the radio won't actually work over these ranges, but the RSS will now allow ham band freqs. We've found that the mobiles will actually "lock" the VCO across the entire band, but the receiver gets REAL deaf below 920 or so, because of the front-end filters. The HT will drop out of lock at the low end of the band for receive, and its receiver performance is similar to the mobile. The filters can be changed, of course!
[ if you wanted to take an 800 "out of band", just calculate the original binary numbers and you can find them in the file - then change them, not forgetting to "adjust" for the checksum!]
Clearly, a GTX with no trunking channels has a lot of extra EEPROM left, but I know of no way to gain extra conventional channels - but if someone knows, I would sure like to hear about it!
It will take a lot more than just "sniffing out" the band-limit numbers, I'm afraid..
73 DE Hartley W1OQ
<font size=-1>[ This Message was edited by: Hartley on 2001-11-16 22:34 ]</font>
<font size=-1>[ This Message was edited by: Hartley on 2001-11-16 22:38 ]</font>
<font size=-1>[ This Message was edited by: Hartley on 2001-11-16 22:41 ]</font>
OK - there are a couple other numbers in there that we didn't look at, but since we don't have to change them, that's OK. They express the range as two separate ranges - in the "STOCK" version, the rptr transmit range is 896-902 >> so we change the top end to something higher, like 941 (higher than we need, but the number is already there as the top of the receive/talkaround TX range, so it is easy to use - no calculations!). The "stock" receive/talkaround range is 935-941, so we change the low end to something lower, like the 896 that is already the lower limit for the rptr TX range (look at the .mdf file & you will see them!). Naturally, the radio won't actually work over these ranges, but the RSS will now allow ham band freqs. We've found that the mobiles will actually "lock" the VCO across the entire band, but the receiver gets REAL deaf below 920 or so, because of the front-end filters. The HT will drop out of lock at the low end of the band for receive, and its receiver performance is similar to the mobile. The filters can be changed, of course!
[ if you wanted to take an 800 "out of band", just calculate the original binary numbers and you can find them in the file - then change them, not forgetting to "adjust" for the checksum!]
Clearly, a GTX with no trunking channels has a lot of extra EEPROM left, but I know of no way to gain extra conventional channels - but if someone knows, I would sure like to hear about it!
It will take a lot more than just "sniffing out" the band-limit numbers, I'm afraid..
73 DE Hartley W1OQ
<font size=-1>[ This Message was edited by: Hartley on 2001-11-16 22:34 ]</font>
<font size=-1>[ This Message was edited by: Hartley on 2001-11-16 22:38 ]</font>
<font size=-1>[ This Message was edited by: Hartley on 2001-11-16 22:41 ]</font>
Actually you can add a few convetional channels. Works like the Maxtrac. Only problem is the display isn't capable of handling anything higher than 10. The added channel numbers are garbaged. You can count the number of button pushes past 10 and use the extras. Seems like you can go to 15, but no higher.