Maxtrac tuning Data in codeplug? HEX?

[Max-trac]

Has anyone played with finding the xtal and tuning data in a codeplug file for a Maxtrac?
I looked and could not find it.
Sometimes the sticker is missing or illegable, and when doing a full alignment, those fields do NOT pop up like the rest do.

Also does anyone know how exactly the values affect things?
There are range limits in each field and different models have different ranges. Example; A LOW SPLIT VHF HAS DIFFERENT LIMITS THAN THE HI SPLIT VHF! So when telling a Hi split it is a low split (so it will align correctly at 145) sometimes the tuning data is out of range!

[kcbooboo]

That would be nice to have. I wish that RSS would display the previous values of the crystal data fields so if nothing else you could make new labels and put them on.

I have a few 800 MHz radios at my disposal that I could blank, look at the codeplug, then initialize the radio and see how much stuff changed.

Bob M.

[kb0nly]

That's one thing i have been wondering myself. It must be stored in the codeplug data since it gets input and written to the radio, but for some reason it doesn't get displayed when reading the radio.

[Max-trac]

If we can figure out where to look in the coldeplug,
we could also try this;
See if it saves the old data (vs entering zeros) if you hit F10 to skip that step (vs F8 to save).

[xmo]

Way back when Maxtrac was new - before Motorola put the shift entry trick in the RSS - we used to do out of band mods by bit-tweaking the archive files.

It should be possible to do the same for the tuning data. Start by blanking a radio, then initialize it and enter the tuning data. For expediency, don't alter any of the default alignment data on the rest of the screens. When done, save the archive file, then using DOS rename the file to a temporary name.

Then repeat the process of initialization exactly the same way. Read the radio and save the archive. Those files should match if the process was identical.

Next blank the radio again and initialize it one more time but change one character of the tuning data. The archive file from that process should differ. The locations where there are differences should be the location where the tuning data is stored and the checksum location(s).

It would be a lot of work but once mastered it should be possible to find the tuning data in an existing radio's archive file. That would be a big help now that Maxtracs are older and some of those stickers are gone or unreadable.

[Max-trac]

Yes, I've been meaning to do something similar, just low on my list and had hoped someone had done it already.

This would be very helpful also to locate the tuning freqs so we could maybe change the 146 to 145 etc...!

[wavetar]

That's one thing i have been wondering myself. It must be stored in the codeplug data since it gets input and written to the radio, but for some reason it doesn't get displayed when reading the radio.

I think you would have to change things like the tuning frequencies by bitbanging the EEPROM, not hex editing the codeplug....the data gets input into the radio through RSS, this is true, BUT it's only while in 'service alignment' mode this is possible. It seems to exist in a part of the EEPROM which isn't normally read by the RSS. I would think if it was there, it would be easily found just like the regular bandsplit information.

You should be able to find the xtal info through the bitbanging method as well.

Todd

[Max-trac]

Hmmm..yes I guess the tuning freq limits would be in the RSS or .mdf file, then maybe dumped to eeprom when initializing.

And I know you can read/write to the radio from the service screen and change stuff without reading or writing to the radio (in the normal codeplug way) and the tuning values "stick".

But aren't the tuning values stored in the codeplug too?
Because I pulled an OLD codeplug that I had set for lowpower and put it into the radio (that I had since set for high power) and it then was set for low power......

[wavetar]

Where did you set the low power? In the service alignment? I've cloned a lot of Maxtracs over the years, I've never seen the softpot settings transfer (unless you were forcing with LAB?)

Oh, here's a thought...are the codeplugs encrypted? I haven't played with hex editing in Maxtracs all that much.

Todd

[Max-trac]

I had changed the power in the regular service screen, NOT the replace logic board full alignment.

But it was not a clone.. it was two codeplugs from the same radio that I had stored in different directories....

I will have to play and confirm, but that is why if I do any servicing, I read and save when I am done.

[kcbooboo]

I did find lists of tuning frequencies in the Maxtrac.exe file. Whether these are stored in the codeplug when it's initialized or blanked is not known yet. They also might not even be in the radio; the service software could just tell the radio to transmit on a specific frequency.

The values are stored in the 8-byte floating point format. Here's the 136-174 MHz data that I found. The first column is the hex address, the next 8 values are the 8 bytes of data, and the last column is the actual decimal value it represents. The addresses may be different depending on the version of the program you have. The lists cover 25 thru 941 MHz.

0004DC0A: 00 00 00 00 00 00 61 40 = 136.0000000000
0004DC12: EC 51 B8 1E 85 37 61 40 = 137.7350000000
0004DC1A: D7 A3 70 3D 0A 6F 61 40 = 139.4700000000
0004DC22: C3 F5 28 5C 8F A6 61 40 = 141.2050000000
0004DC2A: AE 47 E1 7A 14 DE 61 40 = 142.9400000000
0004DC32: 9A 99 99 99 99 15 62 40 = 144.6750000000
0004DC3A: 85 EB 51 B8 1E 4D 62 40 = 146.4100000000
0004DC42: 71 3D 0A D7 A3 84 62 40 = 148.1450000000
0004DC4A: 5C 8F C2 F5 28 BC 62 40 = 149.8800000000
0004DC52: 48 E1 7A 14 AE F3 62 40 = 151.6150000000
0004DC5A: 33 33 33 33 33 2B 63 40 = 153.3500000000
0004DC62: 1F 85 EB 51 B8 62 63 40 = 155.0850000000
0004DC6A: 0A D7 A3 70 3D 9A 63 40 = 156.8200000000
0004DC72: F6 28 5C 8F C2 D1 63 40 = 158.5550000000
0004DC7A: E1 7A 14 AE 47 09 64 40 = 160.2900000000
0004DC82: CD CC CC CC CC 40 64 40 = 162.0250000000
0004DC8A: 00 00 00 00 00 40 62 40 = 146.0000000000
0004DC92: 00 00 00 00 00 7C 62 40 = 147.8750000000
0004DC9A: 00 00 00 00 00 B8 62 40 = 149.7500000000
0004DCA2: 00 00 00 00 00 F4 62 40 = 151.6250000000
0004DCAA: 00 00 00 00 00 30 63 40 = 153.5000000000
0004DCB2: 00 00 00 00 00 6C 63 40 = 155.3750000000
0004DCBA: 00 00 00 00 00 A8 63 40 = 157.2500000000
0004DCC2: 00 00 00 00 00 E4 63 40 = 159.1250000000
0004DCCA: 00 00 00 00 00 20 64 40 = 161.0000000000
0004DCD2: 00 00 00 00 00 5C 64 40 = 162.8750000000
0004DCDA: 00 00 00 00 00 98 64 40 = 164.7500000000
0004DCE2: 00 00 00 00 00 D4 64 40 = 166.6250000000
0004DCEA: 00 00 00 00 00 10 65 40 = 168.5000000000
0004DCF2: 00 00 00 00 00 4C 65 40 = 170.3750000000
0004DCFA: 00 00 00 00 00 88 65 40 = 172.2500000000
0004DD02: 00 00 00 00 00 C4 65 40 = 174.1250000000

I used Hex Workshop to find the table, then wrote my own program to dump/convert the values between two hex addresses. This works in any file that uses this format, which includes GTXs and Spectras.

Bob M.

[kcbooboo]

I did some fooling with a 2ch 800 MHz conventional MaxTrac today. I saved the original codeplug, which was the result of a full initialization and alignment of the radio.

I blanked it and initialized it as a D45MJA73A6_K with a serial number of 123ABC4567. I said it was a standard product, MaxTrac 100, 806-870 MHz, panel 000, 2ch, 35w, talk-around, PL/DPL. I wrote these values to the radio with F8, then read and saved the codeplug and copied it elsewhere.

I got back into the program and went through the first step of the board initialization procedure - the crystal data screen. I entered 5555 6666 for the crystal data, 222 3333 - for the tuning data, and 9.75 for the 9.6V value. I wrote these values to the radio with F8, then aborted the rest of the procedure by hitting F10. I read and saved the codeplug and copied it elsewhere.

I did find out that the tuning data can run from 211-299, and 3000-6000. I did not play with the crystal data, but I presume it has limits as well. The 9.6V value can go from 9.40 to 9.80.

I loaded the original codeplug back into the radio and took the saved codeplugs elsewhere for analysis with Hex Workshop.

I found that there's a checksum at byte 182 that covers the first 181 bytes. This is the 2's complement of an 8-bit checksum. Most of the rest of the file is hex FF bytes.

I saw a copyright notice in the beginning of the codeplugs, as well as the ASCII serial number. Nothing else made any sense at all. I couldn't find any correlation between the values I entered and the data in the file. I looked using both Intel and Motorola data formats. All of the codeplug files were 512 bytes long. There's not enough data in it to account for the tuning and alignment values.

I did notice that the software displays messages about decoding codeplug data at several points. Considering how long it shows that message, and the fact that there's only 512 bytes in the saved codeplug, it must be doing an awful lot of computing (I'm using a Pentium 100 MHz laptop) or crunching the data multiple times to make something useful out of it.

If anyone wants to look at the data I extracted, send me a PM with an e-mail address and I'll get them off to you.

Bob M.

[kcbooboo]

I did a quick experiment with a program today. I put an 800 MHz non-talk-around radio on the bench and went into the PA replacement menu. The first transmit frequency is 804.8625 MHz.

I then hex-edited an EXE file and changed that value in a big list of tuning frequencies to be 804.0000. When I ran it on the same radio, the first PA tuning frequency was now 804.0000.

Nothing else was changed. I did NOT have to fix any checksum.

I don't know how the radio decides how a programmed frequency is matched to the 16 tuning bands the radio has stored within it somehow. Whether this is put in during blanking or initialization is unknown. The fact that I could change a tuning frequency for the duration of that procedure does not yet confirm that the radio will remember that frequency and use it as one end of a range limit.

Take, for example, a radio that has 16 tuning freqs between 32 and 66 MHz (this is an imaginary example). This means that each band is 2 MHz wide, so the radio might want to tune things up on 33, 35, 37, etc. If it's told to transmit on 34.9 MHz, it would use the tuning data for the 2nd band, from 34 to 36 MHz, and use the value for 35 MHz. This is how I think the radios operate internally. Thus, they only need one list of frequencies which can handle both output power and deviation setting.

When a radio is programmed with operating frequencies, the program could read, or already know, these band limits, and decide that 34.9 MHz is in band 2, and send the value "2" to the radio, so the radio then knows what tuning values to use for power and deviation. If it did this, then the table of frequencies would not need to be stored in the radio itself.

If this is how it works, then a modified program would make decisions based on the values it knows about, which may NOT match those that the radio is expecting. Say, in the above example, we changed the lowest range from 32 to 42. If we programmed in a frequency of 45 MHz, the radio would be told to use band "2" tuning values, but the radio would consider that frequency to be somewhere in band 7, based on the data it got when it was first blanked or initialized.

Unfortunately I need a 900 MHz radio to test this further, because those are notoriously bad at controlling transmit power between 902 and 935, frequencies that it normally is not expecting to operate on. If my idea of how the radio works is close to reality, a 927 MHz frequency might take on the tuning value for the band between 902 and 935, and there IS no band there, hence the output power is some random value.

More as I find out what's going on.

Bob M.

[Max-trac]

If you have a VHF radio, as soon as you go below 146, they run wide open. You would need to check this beforehand to see what it is actually putting out, some go way high, some are reasonable.
The same is true for anything above 50 megs in a lowband unit.

I have a low band unit to tune up so I may look in the .exe file and move the 50 limit up but wonder how it really works ,,,as you mention...

[kcbooboo]

Come to think of it, I have a VHF radio that does exhibit that problem, and it should be easy to change the first tuning frequency to 144, then blank and reinitialize the radio and enter a frequency there and see what it does.

I am expecting that you'd need to make this change in any and all programs that will ever be used with this radio, so the tuning freq is maintained below 146.

Bob M.

[jackhackett]

Aren't the EEPROMs in some of the Maxtracs socketed? If so you could read one in an EEPROM programmer to get at the parts RSS won't read.


Also, is there any chance that the data in question is stored in the processor itself? There's 512 bytes of EEPROM in the 68HC11 they use.

[kcbooboo]

Yes, there is some EEPROM data in the CPU, and I think this is where they keep the tuning data, and maybe the serial number and model number.

I personally haven't run across anything else socketed, unfortunately.

Bob M.