Si570 Programming - Random Thoughts

In thinking about alternative methods of calculating the necessary parameters for the Si570 frequency setting elements, other than double precision floating point math, I have considered a number of approaches.

• Fixed point math
• Table lookup

The application of fixed point math is certainly a viable approach and one that I plan to complete an implementation of for purposes of comparison of strengths and weaknesses.  I wondered however about the need for such an approach when I consider a number of characteristics of the Si570.

• There is a fair amount of frequency excursion that is possible without changing the values of N1 and HSDiv.
• For any given pair of N1 and HSDiv, there is a minimum and maximum frequency that can be represented.
• For a desired frequency increment within the minimum and maximum range of the N1 and HSDiv values currently set, there is a value that must be added to the current RFREQ value to change the frequency by that increment.

One could envision an approach where a table of output frequency ranges is stored consisting of an RFREQ, N1 and HSDiv value for the start of the range.  For the set of frequency increments desired (1Hz, 10Hz, 100Hz, 1kHz, etc) a RFREQ increment could be calculated in advance and stored with the rest of the table entries.

The frequency setting calculation for Si570 as we know is:

  fOut = fXtal * RFREQ / (N1 * HSDiv)

A change of frequency without changing N1 or HSDiv might be represented as follows:

  fOutNew = fXtal * (RFREQ + delta) / (N1 * HSDiv)

In practice, it might be tempting to calculate a single value for the smallest frequency change we wish to be able to apply and then just multiply that value by the number of increments of that amount we wish to make.  For example, if we decide the smallest frequency increment is 1Hz and calculate a value for delta necessary to move the output frequency by 1Hz, then to move 10Hz, we would just multiply the value by 10 and add it to RFREQ.  I think there is some danger in this approach that may or may not be sufficiently significant, depending on the application.

Any errors involved in the calculation of the stored values for RFREQ and delta will tend to accumulate.  These errors may in fact be very small, but it should be considered.  Calculating the values for several frequency increments in advance and always using the largest increment first where possible may help to minimize such errors at the expense of a little more table space.

It may also be desirable to store more than one value for RFREQ depending on the amount of error between the bottom and top of the range represented by the values of N1 and HSDiv.  Perhaps storing a value for the middle of the range rather than either end of the range or maybe storing a value for the top and bottom of the range.  The amount of error accumulation will need be analyzed and an appropriate scheme chosen to meet the accuracy needs of the application.

I believe it should be possible with a couple dozen table entries to represent the entire range of the CMOS version (10-160 MHz) with this approach with sufficient frequency setting resolution to implement a general purpose VFO or general coverage receiver.

Another item to consider for any table driven approach is how to calibrate the values stored.  An overall calibration value is unlikely to be applicable across the entire Si570 frequency range.  It may be that calibration values will need be determined and stored for each pair of N1 and HSDiv.

More to come...