Well, it is finally done. We finally have the information on how to change the bandsplits in the Spectra RSS. This will allow you to stretch the operation of the radio as far as the hardware will allow.
The information presented here will allow you to change any of the bandsplits you are interested in, whether that is VHF, UHF, or 900.
This hack all started when XMO did some research into the inner workings of the Spectra RSS. He tried all the usual ways that work with other RSS in order to find the band limits, but as many of you know, that doesn't work. When he hit that brick wall, he didn't stop. He decided to look into it further. We are all very glad he did.
Here is an excerpt from an email we received from XMO:
"I found some information at Microsoft and also in a QBasic newsletter. These sources explain how numbers are stored in a computer. The Basic language reference manual also offers some help. Since computers only speak binary, program language creators developed several ways to store numbers. The simplest is integer where two bytes can represent a number from +32767 to - 32768. Then there are the floating point numbers which can be either single precision which takes 4 bytes to store or double precision which takes 8 bytes to store. Further complicating the issue is the fact that Microsoft originally used a proprietary format - Microsoft Binary Format - MBF. Later they changed to an IEEE format. QB45 uses the IEEE floating point format, as does the Spectra RSS. Had I done this project with interpreted BASICA which uses the MBF I might still be banging my head against the wall!"
This was the key that unlocked the world! Once it was determined that the bandsplits were being stored as double precision floating point, everything else falls into place.
As an example of how these numbers are stored, take the band limit of 902 for example. If you convert this to a double precision floating point number, you get 00 00 00 00 00 30 8C 40.
Once some numbers were crunched, and some utilities written, the bandsplit table in the Spectra RSS suddenly appeared! You can download the utilities for your own use by clicking here. Contained in the zip file are two small DOS programs. One will convert an integer (like 902) into a double precision floating point format, the other utility will convert from floating point format back to an integer.
The image above shows the bandsplit table for version R06.00.05 of the Spectra RSS. It is located in the Spectra1.exe file, starting at offset 0x4B48A.
Of course this looks like a bunch of garbage, but if you start converting the floating point numbers back to decimal format, a more meaningful table appears:
0004B48A 900 896 902 935 941 935 941 896 941 0004B4D2-0004B571 Model number information 0004B572 150 133 171 133 171 133 171 136 162 0004B5BA 150 142 175.5 142 175.5 142 175.5 146 174 0004B602 450 403 441 403 441 403 441 403 433 0004B64A 450 438 470 438 470 438 470 438 470 0004B692 450 440 491 440 491 440 491 450 482 0004B6DA 450 453 491 453 491 453 491 453 488 0004B722 450 475 515 475 515 475 515 482 512 0004B76A 800 803 825 851 870 851 870 806 870 0004B7B2 900 892 895 902 931 941 931 941 892 0004B7FA 941
This is where things get interesting. If you look at the first column of frequencies, they all refer to the general band that the radio is operating in; 900 for 900MHz, 150 for VHF, 450 for UHF, and 800 for 800MHz.
The next two columns of frequencies appear to be the receiver limits. The two columns of frequencies after that are not yet known as to what they affect, talk-around limits maybe? The two columns following that are for the transmitter limits. And finally, the last two columns determine what is shown in the Radio Wide screen in the RSS.
So, that leaves us with the following layout:
Band RXlo RXhi ? ? TXlo TXhi RSSlo RSShi
There are a couple of quirks to be aware of in this table. The first is where the 900 limits are, one at the beginning of the table and the other at the end. The one at the beginning looks like it has "normal" limits, while the one at the end seems screwed up. Be aware of that when you are messing with your 900 radio and can't figure our why your changes don't work when you program your radio, you may be editing in the wrong spot.
The other quirk is the 941 that is located at the end of the table. We have no idea why this is where it is. The only theory that we can come up with is that if you ignored the 892 that is present at the beginning of the previous table entry, and shifted everything back, the limits would make more sense... who knows. Just something to be aware of.
Now that we know what the layout is, we can start to modify things to our liking.
RIGHT NOW IS A GOOD TIME TO MAKE A BACKUP COPY OF YOUR Spectra1.exe FILE! If you screw up in the next steps, you can always go back to default and start again.
The most important thing of this whole next exercise is to understand that in order for the RSS to run, it has to think that it has not been modified. The way for the RSS to verify this is to calculate a checksum of the file when it starts and compare that to what it expects. If the result it gets from its calculation is different from what it is expecting, then the RSS assumes that the file is corrupt and halts (crashes).
For us to make our changes, we need to take a checksum calculation of the file before we start, again after we finish, and then correct the file to get the proper checksum (that we started with) to make our modifications look transparent to the RSS.
Using Hex Workshop, you can do this by going to the Tools menu, selecting Generate Checksum, and then select Checksum (16-bit) for the Entire Document and click Generate. This should pop up a results dialog at the bottom of the screen that looks like this:
As you can see, the checksum for this file is 0x3540. Write down your result, you will need it later.
In this example, we will change the band limits for a 453-488 radio down to 440. In this version of RSS, the 450-482 radio is already lowered to cover the ham band, so there is no point in modifying it.
By using the utilities and information mentioned above, and searching through the Spectra1.exe file, we find that the bandsplit entry for the radio starts at offset 0x04B6DA, with the first occurance of 453 (00 00 00 00 00 50 7C 40) at offset 0x04B6E2.
Again using the utilities, and figuring out that 440 is represented by 00 00 00 00 00 80 7B 40, we replace all the 50 7C 40 (453) with 80 7B 40 (440).
You should now have something like the above.
Now, if we do the checksum calculation again, we find that it has changed from what we started with.
In order for us to get the checksum back to where we started, we will need to change some other bytes in the file. If you scroll further down in the file, you will come across some error message like this. This is usually a good place to make your changes, since if you were to get this error in real life, you have more serious problems with your RSS.
In order to fix the checksum, start changing a byte and re-calculate the checksum to see if it is closer or further from your desired result. As an example, you could take the 0x4E located at offset 0x04B9E5 (which is really the letter N in Negative), and change it to 0x4F. If you recalculate the checksum, instead of 0x35FC we now get 0x35FD. This is not closer to the 0x3540 that we want, so lets try going the other way. If we change the byte at 0x04B9E5 to 0x4D (remember it was 0x4E, we changed it to 0x4F), re-calculate the checksum, and we get a checksum of 0x35FB. This is closer to 0x3540, so we know we are now going the right way.
Keep changing that byte until you get close to 0x00 (if you are going down) or 0xFF (if you are adding to the byte). You can go in bigger steps if you want, not just adding or subtracting one at a time. Just keep checking to see if you are getting close to your checksum that you want (0x3540 in our example). If you get to 0x00 (or 0xFF) and are not at your desired checksum yet, move over to the next byte and continue the process. Eventually you should be able to add (or subtract) enough to get the checksum back to where you want it.It is important to only change text messages! If you change random locations in the file, you are really changing the operating code in the software, and it will cause the RSS to crash. This is the reason we are changing the error message that says "Negative number in SetVector", so that we don't change any of the actual operating code for the program.
Continuing with our example, after changing enough bytes, we finally get the following:
If you calculate the checksum on this, you will see that it is exactly what we want, 0x3540.
Thats it! Save the file, fire up the RSS and enter the frequencies you want.
Don't stop reading though. You MUST understand a couple of things.
First, while this procedure will make it possible for you to enter the frequencies into the RSS and program the radio. It DOES NOT mean that the radio will actually work on the frequencies you want. If you try and operate on frequencies that are outside of the limits of the hardware, the first thing to usually go is the VCO, which is indicated by the FL/01 or FAIL 001 error. There are some VCO tweaks that can help extend the range a bit, but you can only go so far.
This leads to the second point. You cannot change the bandsplit of your radio just by changing the frequencies in the RSS. There is no way that by programming 146.520 into your UHF Spectra that you can even think that it will work. It won't, and it never will. The UHF and VHF radios use entirely different RF sections. Likewise, you will not make a 438-370 radio do 403-433, they again use different RF sections.
These band limit modifications are merely for stretching the existing limits of the software to get the most out of the hardware in the radio. They are not a miracle.
There you go. Hopefully this is clear and concise enough for everyone to figure out how to change the band limits in their Spectra. Motorola made this one a bigger challenge, but through the perseverance of some dedicated people, it was eventually figured out.