At 02:23 PM 10/29/96 -0800, you wrote:
>Shawn,
>
>You might want to check out some simple sine wave theory:
>
>http://www.interstice.com/~sdattalo/technical/theory/sinewave.html
>
>And an implementation with a PIC:
>
>http://www.interstice.com/~sdattalo/technical/software/pic/picsine.html
>
>These may give you a couple of more ideas.
>
>
>I realize that "generating" your sine wave is not necessarily
>the problem. From your description, it sounds as though if there
>is a timing problem. Specifically, you're generating 320 samples
>for a 62.5Hz sine wave, which translates to 1/62.5/320 = 50us
>per sample. This means you need to update the DAC exactly once
>every 50us. And I assume that you're synchronized to the 20kHz
>PWM output to achieve this update rate. Is it possible that your
>crystal is too fast? (62.52-62.5)/62.5 ==> 0.032% error is not
>much error.
>
>
>This problem is solvable by adding more precision to your
>frequency variable. Currently, I assume every 50us you automatically
>increment some kind of "frequency" variable to access the next
>location in the sine wave table:
>
>f = f + 1;   /* Increment at each sample */
>if f>=160 then ... rollover/reverse
>
>However, instead of incrementing by exactly 1.000, you could do
>something like so:
>
>f = f + 1 + eps;   /* Increase f at each sample */
>
>where |eps| << 1. (way less than, not shift left by)
>
>In your case, if the problem really is a fast crystal, then eps
>will be 0.00032. So that after 160 samples, spaced 99.968us
>apart (fast crystal) f will rollover at:
>
>  160 (1 + eps) * 99.968us = 62.5 times per second
>
>The down side is that now you must (perhaps must is too strong)
>interpolate between entries in the sine table array.
>
>There are scaling issues that greatly simplify the problem of
>dealing with floating point numbers. Furthermore, the scaling
>can be designed such that you can take advantage of roll-over
>arithmetic. I'll elaborate if this is not too clear.
>
>
>I've used a variation of this technique for phase-locking to a
>60Hz frequency before. There I used 20bits of resolution in the
>phase increment.
>
>Scott
>
Good suggestion!  But I've never done that sort of math before...  also
things don't really point to the 20 Khz since I already tried an independent
update pulse coming from a counter in a computer sitting on my desk and the
results were EXACTLY the same.  I also tried three different 20 Mhz crystals
in the PIC prduceing the 20 Khz, with no change... So I can only assume this
frequency is correct.