Si570 Programming Continued...

The relationship between the various frequency setting elements is described as follows:

As previously mentioned, the output frequency is the result of the DCO frequency divided by the product of two divisors.  The DCO frequency is the product of a crystal frequency in the 114.25 MHz range and a settable reference frequency and must remain within the range of 4.85 to 5.67 Ghz.  RFREQ has 38 bits of resolution allowing for a theoretical frequency setting resolution of 0.09 ppb at the test frequency of 114.285 MHz.

The HSDIV and N1 values have additional restrictions on them, specifically HSDIV can have the values 4, 5, 6, 7, 9 or 11.  N1 can be 1 or any even number up to 128 inclusive (1, 2, 4, 6, ... 128).

Typically at startup you would determine the fxtal value specifically for your chip:

By interrogating the chip, one can determine the values for HSDIV, N1 and RFREQ.  By knowing the default startup frequency, the crystal frequency can be calculated.  In my case, HSDIV = 11, N1 = 8 and RFREQ is 0x2B6109f08.  Dividing this value by 2^28 gives me 0x2b as the integer portion or 43 decimal.  To figure out the fractional part one would divide 0x6109f08 (the least significant 28 bits of RFREQ) by 2^28.  Working in decimal instead of hex:

  0x6109f08 = 101752584 / 2^28 = 0.3790579140

Adding this to the integer portion gives me a RFREQ value of 43.3790579140.  Plugging this and the other knowns into the formula above gives me:

  fxtal = (56320000 * 11 * 8) / 43.3790579140 = 114252365.964832 or 114.252365 Mhz

The datasheet states that the crystal frequency is only accurate to +/- 2000 ppm at 114.285 Mhz, or about +/- 0.22857 so my device is within the pretty horrible specification.

So, running this the other way, the output frequency is found as:

  fout = (114252365 * 43.3790579140) / 11 * 8 = 56319999.524391 = 56.32 Mhz

A guy could envision a mechanism wherein you output a WWV frequency and tweak RFREQ until zero beat and then store the value for future reference, but the known frequency technique will get you very close.

If the DCO frequency is only moved +/- 3500 ppm, the oscillator output will be phase continuous.  This should make implementing protocols such as WSPR, JT65 and the like much cleaner than my previous work using the Parallax Propeller.  Also, in theory there is .42 Hz frequency resolution capable which would allow for much closer FSK tone shifts used in WSPR than the 1Hz resolution I had with the propeller.

It is unclear from the datasheet what is precisely meant by the +/- 3500 ppm figure.  One interpretation is that once you have moved a total of 3500 ppm from whatever frequency you last set using the "large frequency change technique", you would have to recalculate the RFREQ and divisor values and set them back to the device.  In my experience, most of the Arduino implementations I have reviewed have taken a flavor of this approach.  While this is certainly safe, it is unlikely to be necessary.  The other interpretation I have of the datasheet is that you could move the DCO over its entire range without recalculating parameters and do it in a phase continuous manner as long as no single frequency change is more than 3500 ppm.  My interpretation is that once you have changed the frequency by either of these mechanisms, the new DCO frequency (not the output frequency) becomes the new "center frequency" described in the datasheet.  So, under my theory, you could move the output frequency a total of 5.67 - 4.85 GHz = 0.82 Ghz 3500 ppm at a time.  Of course, this would require a different part than I have which only has a range of 10-160 Mhz.  Under this theory, as long as you didn't jump more than 17.5 Mhz between frequency settings, you only have to recalculate RFREQ and the change in frequency could be done phase continuous.  This theory I have not yet tested.

More to come...