A new recursive quadrature oscillator

Hi, I would like to ask your opinion about a new recursive oscillator that
I came up wiith:
http://vicanek.de/articles/QuadOsc.pdf
One should think that everything has been said and done in this area,
however I am not aware of any existing (recursive) oscillator which
comprises all of the following features: 
(1) (hyper)stable (i.e. no exponential runaway)
(2) quadrature output
(3) equal amplitudes
(4) low-frequency accurate
(5) reasonable CPU load (3 adds and 3 multiplies per sample)
I have done a thorough research to check that this hasn't been published
before but of course I might have missed something. Thanks for your
feedback!
Martin

---------------------------------------
Posted through http://www.DSPRelated.com

Martin

Nice paper, very well explained. I've used recursive oscillators in the past and always had trouble with amplitude changes during on-the-fly coefficient updates (doing a linear or log frequency sweep, for example). I couldn't quite tell if your oscillator was free of this problem or just a little better compared to other forms. 

I always wondered if you could re-time the parameter changes so they coincide with the phase angle that corresponds to the initial reset condition. Since you can't expect that the phase angle will ever return exactly to the initial condition, you could perhaps keep track of the phase error when the coefficient update occurs and noise-shape this error by adjusting the timing of the update. On the other hand this is complicated enough that most people would just use an interpolated lookup table instead. 

Bob

Hi,
This is very cool indeed. It would be interesting to add a section about
fixed-point behavior. Are extra bits needed if a result of N bits is
desired on the outputs?
---------------------------------------
Posted through http://www.DSPRelated.com

On 10/15/15 11:16 AM, radams2000@gmail.com wrote:
> Nice paper, very well explained. I've used recursive oscillators in the past and always had trouble with amplitude changes during on-the-fly coefficient updates (doing a linear or log frequency sweep, for example). I couldn't quite tell if your oscillator was free of this problem or just a little better compared to other forms.
>
> I always wondered if you could re-time the parameter changes so they coincide with the phase angle that corresponds to the initial reset condition. Since you can't expect that the phase angle will ever return exactly to the initial condition, you could perhaps keep track of the phase error when the coefficient update occurs and noise-shape this error by adjusting the timing of the update. On the other hand this is complicated enough that most people would just use an interpolated lookup table instead.
>

On 10/15/15 11:54 AM, gretzteam wrote:
> This is very cool indeed. It would be interesting to add a section about
> fixed-point behavior. Are extra bits needed if a result of N bits is
> desired on the outputs?


lessee...

     tmp = u[n] - k1*v[n];
     v[n+1] = v[n] + k2*tmp;
     u[n+1] = tmp - k1*v[n+1];

so

     v[n+1] = v[n] + k2*(u[n] - k1*v[n])
            = k2*u[n] + (1-k1*k2)*v[n]

and

     u[n+1] = u[n] - k1*v[n] - k1*v[n+1]
            = u[n] - k1*v[n] - k1*(k2*u[n] + (1-k1*k2)*v[n])
            = (1-k1*k2)*u[n] - k1*(2-k1*k2)*v[n]


and i seem to remember that

      u[n+1] = cos(w)*u[n] - sin(w)*v[n]
and
      v[n+1] = sin(w)*u[n] + cos(w)*v[n]

    so    1-k1*k2 = cos(w)
   and    k2      = k1*(2-k1*k2) = sin(w)

is that the case?  i haven't cranked it out but the latter looks suspect 
to me.



-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

Guys, thanks for your comments.

[...]
>(5) reasonable CPU load (3 adds and 3 multiplies per sample)

Actually only 2 multiplies if you save the product k1*v[n+1] and use it in
the next iteration step ;-)

>Nice paper, very well explained. I've used recursive oscillators in the
>past and always had trouble with amplitude changes during on-the-fly
>coefficient updates (doing a linear or log frequency sweep, for example).
I
>couldn't quite tell if your oscillator was free of this problem or just a
little
>better compared to other forms. 
>[...]Bob

That's one of the advantages of an equal-amplitude quadrature oscillator:
updating coefficient on-the-fly does not change the amplitudes nor the
phase relation, the whole thing simply rotates at another speed from there
on. It's like a rock solid wheel. :-) Obviously I forgot to state this in
my write-up, need to include that.

>[...] It would be interesting to add a section about
>fixed-point behavior. Are extra bits needed if a result of N bits is
>desired on the outputs?

Whoa, I have always worked with floating-point so haven't thought about
fixed-point. But yes, I can see the relevance, thanks for the suggestion.

>[...]
>    so    1-k1*k2 = cos(w)
>   and    k2      = k1*(2-k1*k2) = sin(w)
>
>is that the case?  i haven't cranked it out but the latter looks suspect

>to me.
>
>r b-j

Yup, all correct! (I admit the second equality is not immediately
obvious.) However, if you eliminate tmp like you did you end up with a
coupled form oscillator, which has 4 multiplies and is unstable. So for
the actual iteration it is better to leave tmp in. 
---------------------------------------
Posted through http://www.DSPRelated.com

>>[...] It would be interesting to add a section about
>>fixed-point behavior. Are extra bits needed if a result of N bits is
>>desired on the outputs?
>
>Whoa, I have always worked with floating-point so haven't thought about
>fixed-point. But yes, I can see the relevance, thanks for the
suggestion.
>


Here is another question: say you want to use this to generate sin/cos as
part of a demodulator where the carrier frequency (fc) is an INTEGER
multiple of the sampling rate, say fc = fs/32. You really are only
repeating 32 samples over and over. 

By quantizing the coefficients to B bits, we are essentially losing that
'ideal' relationship, and are generating a frequency 'close' to the
desired one, but not dead on. Can you think of some transformation that
would allow exact quantization of coefficients for frequencies at integer
multiple of the sampling rate?

---------------------------------------
Posted through http://www.DSPRelated.com

>Here is another question: say you want to use this to generate sin/cos
as
>part of a demodulator where the carrier frequency (fc) is an INTEGER
>multiple of the sampling rate, say fc = fs/32. You really are only
>repeating 32 samples over and over. 
>
>By quantizing the coefficients to B bits, we are essentially losing that
>'ideal' relationship, and are generating a frequency 'close' to the
>desired one, but not dead on. Can you think of some transformation that
>would allow exact quantization of coefficients for frequencies at
integer
>multiple of the sampling rate?

Okay, in that case you'd probably want to store the 32 sine/cosine values
in a table and just cycle your pointer. I can't think of an easier way.
---------------------------------------
Posted through http://www.DSPRelated.com

>>Here is another question: say you want to use this to generate sin/cos
>as
>>part of a demodulator where the carrier frequency (fc) is an INTEGER
>>multiple of the sampling rate, say fc = fs/32. You really are only
>>repeating 32 samples over and over. 
>>
>>By quantizing the coefficients to B bits, we are essentially losing
that
>>'ideal' relationship, and are generating a frequency 'close' to the
>>desired one, but not dead on. Can you think of some transformation that
>>would allow exact quantization of coefficients for frequencies at
>integer
>>multiple of the sampling rate?
>
>Okay, in that case you'd probably want to store the 32 sine/cosine
values
>in a table and just cycle your pointer. I can't think of an easier way.
>---------------------------------------
>Posted through http://www.DSPRelated.com


Sure, and that was it typically done. However, that table might grow quite
a bit the day you need to support 16 different 'carriers' etc. I was
wondering if this could be used as an extremely clever way to compress all
those tables, but it seems like the coefficients will never nicely
quantize for those cases.
---------------------------------------
Posted through http://www.DSPRelated.com

I implemented it in FreeBasic and it worked very well.  It could be useful for doing computer graphics.

>I implemented it in FreeBasic and it worked very well.  It could be
useful
>for doing computer graphics.

Cool :)
---------------------------------------
Posted through http://www.DSPRelated.com