DSPRelated.com
Forums

Small periodic errors in DPLL's VCO voltage

Started by Ulrich Bangert October 11, 2006
Hi folks,

i have come across a strange phenomenon that i am fighting with since days
now and the time has come that i am completely out of any ideas. That is why
i am asking you.

I sample fixed frequency sinusoidal audio signals of abt. (but not exactly)
100 Hz with a semi-professional 24 bit sound card and a pc. For calculations
that are beyond the scope of this mail i need a representation of these
signals that is less noisy than the input signals and has has a fixed
amplitude regardless of the input amplitude. From my analogue design
experience this should be the classical case to solve with a PLL or more
precise with a DPLL.

So i modelled me a DPLL and made experiments with it. In general, the DPLL
works exactly as expected with all gains and loop filter time constants
having exactly the expected effect on its overall dynamic behaviour.

Now comes the strange thing: If one looks at the DPLL's vco voltage (i.e.
the numerical value that represents it) in the locked condition at a very
fine scale one can see small periodic errors in it. It is not pure dc,
instead it is dc with a small sinusoidal voltage riding on top of it. The
error voltage is REALLY small compared to the dc voltage. To give you an
idea: If the dc voltage level is 3 "Volts" then the sinusoidal error voltage
has a an amplitude of some ten "micro Volts". I agree that this can be
neglected in almost all cases. But my problem is that the math that i am
going to perform on the synthesized signals reacts EXTREME on periodic
changes of its input signals and that is why some microvolts periodic error
on the vco voltage and the accompanying frequency changes of the synthesized
signals are orders of magnitude to great for my job. And no, the error
frequency is NOT double the working frequency of the DPLL as could be argued
for a multiplying/mixing phase detector and a loop filter time constant
giving not enough damping on twice the working frequency! Instead, and this
is the very strange thing, the frequency of the error signal is always at an
low frequency exactly twice the difference between the DPLL's working
frequency and the next "even" frequency in Hz. Let the working frequency of
the DPLL be 100.01 Hz then the difference to the next "even" frequency is
0.01 Hz and the period length of the error signal is 50 s giving a frequency
of 0.02 Hz. The same happens with a working frequency of 99.99 Hz.

Let me explain what i did to nail this effect:

1) Instead of sampling a real world signal i generated my a synthesized
signal within my software as the source signal and let the DPLL run on that,
same effect. So it is not a property of the real world signal, it is
completely buried in the software.

2) I am programming in Borland Delphi 6. This environment has a EXTENDED
data type which repesents floating point numbers in 64 bits. I changed every
floating point number variable to this type to make numerical errors as
small as possible, no change in the effect.

3) A DPLL being a closed loop regulation system CAN be prone to oscillations
with wrong dimensioned gains and time constants. In order to exclude this I
played around with gains and time constants a lot. In regulation theory the
frequency of oscillations depends on the gains and time constants. Not the
case here: Changing the loop parameters had absolutely NO effect on the
frequency of the error signal. Clearly, by making the loop filter time
constant big enough, say 1000 s, even this LF error can be surpressed  but
time constants like that are incompatible to the needed DPLL's dynamics.

4) To exclude that the effect is due to a simple programming bug i took a
MATLAB DPLL simulation example that has been a topic in this newsgroup a
time ago and modified its SYNTAX only to make it work with Borland Delphi.
The computations itself stayed the same: Same effect as with my "own" DPLL.
Due to the fact that I do not own MATLAB I have not been able to test
whether the effect will show up with this environment too.

5) Since the effect seemed to be influenced by the beat frequency of the
DPLL's working frequency and the next "even" frequency i made the
synthesized source frequency an "even" frequency and voila: The error
modulation is no more to be seen.

6) The last idea that i had was that the problem might be due to numerical
errors of the trigonometric computations in Delphi. The vco signal is
computed like vco:=sin(2*Pi*vcofrequency*t+vcophase). Assumed the sin
computation were limited to the first quadrant and all other arguments were
first back-computed to the 0-Pi/2 range then the following scenario were
possible: Assume that the sine computation has numerical errors that are
small at arguments around 0 and big for arguments around Pi/2 (or the other
way round), then looking at a sampled wave of  "even" frequency on a second
by second base would not reveal much of this error. The only noticeable
effect would be a slight amplitude distortion perhaps to small to notice it
all. This being due to the fact that with a "even" frequency the sin is
computed always at exactly the SAME argument positions from one period to
the next period due to the sampled nature of the system and the fact that we
have a integer number of samples per second. However, with a frequency of
100.01 we are NOT exactly at the same phase position after 1 s. Instead we
are n*2*Pi+2*Pi/100 away form "0" with n representing the whole numbers of
cycles of the wave within one second. As is easily seen we need 100 s to get
back to exactly the same phase position. In between a potential numerical
error could get bigger until we reach Pi/2. If it is true that arguments are
back-computed to the 0-Pi/2 range THEN potential numerical errors will get
smaller again after Pi/2 because a positive phase increment after Pi/2 is
back-computed to a negative phase increment in the 0-Pi/2 range so that we
reach the area of smallest errors again at Pi. This could explain why the
error modulation's frequency is TWICE the beat note of DPLL and next "even"
frequency. However, this theory depends on a lot of assumptions and i
thought the simplest check for this theory were to use a computation that
does NOT first back-compute in the 0-Pi/2 range. So i made me my own sin
function using a Taylor series of order 20. I could not use a order higher
than 20 because the n! terms get bigger than MAXINT with n>=21. Much to my
surprise the Taylor series produced pretty much the same effext as the built
in sin computation.

Now i am out of ideas! Please note that this error modulation is absolutely
the only annyoing effect in what i am doing. Everything else works THAT good
that i want to stay at the basic ideas and keep the DPLLS instead of
throwing it all away and search for a different method to get my job done.
Any idea of you which explains this phenomenon is highly appreciated!
Otherwise, if someone can suggest a DSP based phase comparator that does NOT
involve a sin computation, this could would of help too.

TIA
Ulrich Bangert


Ulrich Bangert skrev:
> Hi folks,
...
> Now comes the strange thing: If one looks at the DPLL's vco voltage (i.e. > the numerical value that represents it) in the locked condition at a very > fine scale one can see small periodic errors in it. It is not pure dc, > instead it is dc with a small sinusoidal voltage riding on top of it. The > error voltage is REALLY small compared to the dc voltage. To give you an > idea: If the dc voltage level is 3 "Volts" then the sinusoidal error voltage > has a an amplitude of some ten "micro Volts".
So we are talking about fluctuations on the order of 1e-6... ...
> 2) I am programming in Borland Delphi 6. This environment has a EXTENDED > data type which repesents floating point numbers in 64 bits. I changed every > floating point number variable to this type to make numerical errors as > small as possible, no change in the effect.
I interpret this that there were no chances in either period or amplitude of the effect? If so, this rules out quantization effects... ...
> Any idea of you which explains this phenomenon is highly appreciated!
I haven't studied control systems for a very long time, let alone on this level of detail, so I am by no means sure. The one thing I can think of is that there is something going on inside the DPLL. The DPLL is a feedback system, where some control state necessaily has to fluctuate from some steady state, in order to catch a deviation on the output. Could it be something like this you observe? BTW, I looked into your algorithm for outlier detection you posted here a couple of months ago. There is some potential for speeding up the algorithm. Are you able to link C++ code with your Borland set-up? I see Borland sells a complete bundle of C#, C++, Delphi and Java these days, is this the edition you have? If so, I could mail you my C++ code for you to test. Rune
Hi Rune,

> I haven't studied control systems for a very long time, let alone > on this level of detail, so I am by no means sure.
Me too!
> The one thing I can think of is that there is something going on > inside the DPLL. The DPLL is a feedback system, where some > control state necessaily has to fluctuate from some steady > state, in order to catch a deviation on the output.
Agreed! The DPLL loop filter contains integrator elements that bring the control deviation to "0" but of course this can be interpreted as "mean 0" over some samples and leaves the possibility of small oscillations around the correct value. However the frequency and amplitude of oscillations coming from the regulation process itself are functions of the control system's parameters which is not what i observe. Because of that i think that it NOT control system induced oscillations.
> I see Borland sells a complete bundle of C#, C++, Delphi and Java > these days, is this the edition you have? If so, I could mail you > my C++ code for you to test.
Yes, i have this version available. I would be glad to understand the improvements that you are talking about! Best regards Ulrich "Rune Allnor" <allnor@tele.ntnu.no> schrieb im Newsbeitrag news:1160558136.553703.48510@i3g2000cwc.googlegroups.com...
> > Ulrich Bangert skrev: > > Hi folks, > ... > > Now comes the strange thing: If one looks at the DPLL's vco voltage
(i.e.
> > the numerical value that represents it) in the locked condition at a
very
> > fine scale one can see small periodic errors in it. It is not pure dc, > > instead it is dc with a small sinusoidal voltage riding on top of it.
The
> > error voltage is REALLY small compared to the dc voltage. To give you an > > idea: If the dc voltage level is 3 "Volts" then the sinusoidal error
voltage
> > has a an amplitude of some ten "micro Volts". > > So we are talking about fluctuations on the order of 1e-6... > > ... > > 2) I am programming in Borland Delphi 6. This environment has a EXTENDED
> > data type which repesents floating point numbers in 64 bits. I changed
every
> > floating point number variable to this type to make numerical errors as > > small as possible, no change in the effect. > > I interpret this that there were no chances in either period or > amplitude of the effect? If so, this rules out quantization effects... > > ... > > Any idea of you which explains this phenomenon is highly appreciated! > > I haven't studied control systems for a very long time, let alone > on this level of detail, so I am by no means sure. > > The one thing I can think of is that there is something going on > inside the DPLL. The DPLL is a feedback system, where some > control state necessaily has to fluctuate from some steady > state, in order to catch a deviation on the output. > > Could it be something like this you observe? > > BTW, I looked into your algorithm for outlier detection you posted > here a couple of months ago. There is some potential for speeding > up the algorithm. Are you able to link C++ code with your Borland > set-up? > I see Borland sells a complete bundle of C#, C++, Delphi and Java > these days, is this the edition you have? If so, I could mail you > my C++ code for you to test. > > Rune >
Ulrich Bangert skrev:

> > I see Borland sells a complete bundle of C#, C++, Delphi and Java > > these days, is this the edition you have? If so, I could mail you > > my C++ code for you to test. > > Yes, i have this version available. I would be glad to understand the > improvements that you are talking about!
It will be another week or so until I am back to shore and have access to my private email account. I'll mail you then. Is the email address in this post's header valid? (The address in my posts is not!) Rune

Ulrich Bangert wrote:
> Hi folks, > > i have come across a strange phenomenon that i am fighting with since days > now and the time has come that i am completely out of any ideas. That is why > i am asking you.
Hello Ulrich, The effect that you are describing has to do with the time quantization of your signal. The phase of the DPLL is varying slightly depending on the relative phases of the sampling frequency and the input frequency. Due to that you are getting the variations of everything else. The effect may be more or less pronounced depending on your phase detector, filters and the frequency ratio. The brute force way to deal with it is to oversample highly. The smart way to deal with it is to lock the sample rate on the incoming signal. I.e. keeping the constant ratio. That can be achieved by the interpolation. I hope that helps. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Rune Allnor wrote:
> Ulrich Bangert skrev: > >>Hi folks, > > ... > >>Now comes the strange thing: If one looks at the DPLL's vco voltage (i.e. >>the numerical value that represents it) in the locked condition at a very >>fine scale one can see small periodic errors in it. It is not pure dc, >>instead it is dc with a small sinusoidal voltage riding on top of it. The >>error voltage is REALLY small compared to the dc voltage. To give you an >>idea: If the dc voltage level is 3 "Volts" then the sinusoidal error voltage >>has a an amplitude of some ten "micro Volts". > > > So we are talking about fluctuations on the order of 1e-6... > > ... > >>2) I am programming in Borland Delphi 6. This environment has a EXTENDED >>data type which repesents floating point numbers in 64 bits. I changed every >>floating point number variable to this type to make numerical errors as >>small as possible, no change in the effect. > > > I interpret this that there were no chances in either period or > amplitude of the effect? If so, this rules out quantization effects... > > ... >
I wonder???? I'm no expert in control theory - one semester 40 years ago. But, based on Ulrich saying: " So i made me my own sin function using a Taylor series of order 20. I could not use a order higher than 20 because the n! terms get bigger than MAXINT with n>=21. Much to my surprise the Taylor series produced pretty much the same effect as the built in sin computation." I propose a test case that would _FORCE_ quantization effects to be larger. Use Taylor series of order 14,15, and 16 (order 15 is ~40 bits precision). I suggest running 3 test cases to see the effect (if any) of the alternating sign in the series. I suspect your approximation of sin showing no difference may only indicate that Borland also used a Taylor series ;(
>>Any idea of you which explains this phenomenon is highly appreciated! > > > I haven't studied control systems for a very long time, let alone > on this level of detail, so I am by no means sure. > > The one thing I can think of is that there is something going on > inside the DPLL. The DPLL is a feedback system, where some > control state necessaily has to fluctuate from some steady > state, in order to catch a deviation on the output. > > Could it be something like this you observe? > > BTW, I looked into your algorithm for outlier detection you posted > here a couple of months ago. There is some potential for speeding > up the algorithm. Are you able to link C++ code with your Borland > set-up? > I see Borland sells a complete bundle of C#, C++, Delphi and Java > these days, is this the edition you have? If so, I could mail you > my C++ code for you to test. > > Rune >
Yes,

the address should be ok!

Best regads
Ulrich Bangert

"Rune Allnor" <allnor@tele.ntnu.no> schrieb im Newsbeitrag
news:1160560220.925789.309430@b28g2000cwb.googlegroups.com...
> > Ulrich Bangert skrev: > > > > I see Borland sells a complete bundle of C#, C++, Delphi and Java > > > these days, is this the edition you have? If so, I could mail you > > > my C++ code for you to test. > > > > Yes, i have this version available. I would be glad to understand the > > improvements that you are talking about! > > It will be another week or so until I am back to shore and have access > to my private email account. I'll mail you then. Is the email address > in this post's header valid? (The address in my posts is not!) > > Rune >
Hello Vladimir,

> The effect that you are describing has to do with the time quantization > of your signal. The phase of the DPLL is varying slightly depending on > the relative phases of the sampling frequency and the input frequency. > Due to that you are getting the variations of everything else. > > The effect may be more or less pronounced depending on your phase > detector, filters and the frequency ratio.
The first time i read this i was sure you were wrong but the more i think about it you may be on the right track. However, currently i do not understand well HOW the relative phases of sampling frequency and input frequency in conjunction with time quantization lead to the DPLL's varying phase. Can you elaborate some additional remarks on that?
> The brute force way to deal with it is to oversample highly.
I do already sample at 48 kHz / 96 kHz / 192 kHz which i thought was oversampling enough for a 100 Hz signal! Nevertheless you may be right in that the observed effect is perhaps THAT small BECAUSE i do oversample that much. I will check whether the effect shows any correlation to the quantization size. If there is, i would take it as a proof that you are right.
> The smart way to deal with it is to lock the sample rate on the incoming > signal. I.e. keeping the constant ratio. That can be achieved by the > interpolation.
That sounds indeed to be a very tough idea at the first glance! But: In your above argumentation you made clear that the observed effect is due to errors that arise already in the phase comparator or even before. If i cannot measure the phase correctly how do i manage to make the sampling frequency phase locked to the input frequency? Best regards Ulrich Bangert "Vladimir Vassilevsky" <antispam_bogus@hotmail.com> schrieb im Newsbeitrag news:aC3Xg.13212$e66.5015@newssvr13.news.prodigy.com...
> > > Ulrich Bangert wrote: > > Hi folks, > > > > i have come across a strange phenomenon that i am fighting with since
days
> > now and the time has come that i am completely out of any ideas. That is
why
> > i am asking you. > > Hello Ulrich, > > The effect that you are describing has to do with the time quantization > of your signal. The phase of the DPLL is varying slightly depending on > the relative phases of the sampling frequency and the input frequency. > Due to that you are getting the variations of everything else. > > The effect may be more or less pronounced depending on your phase > detector, filters and the frequency ratio. > > The brute force way to deal with it is to oversample highly. > > The smart way to deal with it is to lock the sample rate on the incoming > signal. I.e. keeping the constant ratio. That can be achieved by the > interpolation. > > I hope that helps. > > Vladimir Vassilevsky > > DSP and Mixed Signal Design Consultant > > http://www.abvolt.com
> > > > > > i have come across a strange phenomenon that i am fighting with since > days > > > now and the time has come that i am completely out of any ideas. That is > why > > > i am asking you. > > >
Urlich, I think the effect you are seeing is due to the FINITE resolution of the Digital VCO (DDS) in the DPLL. Because the VCO resolution is finite, the VCO cannot achieve the EXACT same frequency of the input but can only come very close to it. Since the frequency of the VCO is not exactly the same as the input, a phase error will accumulate until the VCO can jump to the next frequency resolution step. I have often wondered about this myself why this isn't a problem in DPLLs and your post is the first time I have seen it brought up as a problem. You can test to see if this is really the problem by changing the RESOLUTION of the DDS VCO. If I am correct, the frequency jumps you are seeing will be equal to the resolutiuon steps of the VCO. also if you decrease the resolution, the jumps should be larger in magnitude but lower in repetition frequency. And vice versa as you increase the VCO resolution the jumps will be smaller in magnitude but more often in occurance. So you can reduce the magniture of the problem by increaseing the DDS resolution but as far as I can see there is no why to reduce the problem to 0. I suppose if you increase the DDS VCO resolution sufficently, and there is some invevitable phase noise or jitter in the system, the cyclic error will be burried below the random phase jitter. Thank you for the very interesting question. Please let me know what you find. Mark
Hi Mark

and many thanks for your answer.

I think that the effects that you describe are real but have nothing to do 
with my problem. The reason why I think so is

a) the magnitude at which the effect is observed

and

b) the fact that the effect did not change when I changed the DDS phase 
accumulator witdh fro 32 to 64 bit which should have brought a BIG improvent 
according your theory.

To a) The smallest frequency step of a 32 bit DDS is 1/2^32 of the clock 
frequency which already gives us a relative 2.3E-10 resolution, a 48 bit DDS 
makes 3.5E-15 resolution and the 64 bit DDS that i use has a stunning 
5.4E-20 resolution.

So while the proposed frequency jumps as you call them really take place, 
they are orders of magnitude smaller than the observed effect. And once the 
vco frequency has jumped from below the input signal's frequency to above 
the input signal's frequency or the other way round the phase comparator 
changes its sign, so the phase error does not really add up to the magnitude 
of the effect.

A third thing that speaks against your theory is that i do not observe JUMPS 
at all. Within the resolution that i have available the observed effect 
looks pretty much as being continous in amplitude and time although this is 
not exactly possible with a time-discrete and amplitude-discrete system. 
Nevertheless it shows to my opinion that it is not a problem of having too 
less resolution.

Best regards
Ulrich Bangert

"Mark" <makolber@yahoo.com> schrieb im Newsbeitrag 
news:1160571773.618391.53170@b28g2000cwb.googlegroups.com...
> >> > > >> > > i have come across a strange phenomenon that i am fighting with since >> days >> > > now and the time has come that i am completely out of any ideas. That >> > > is >> why >> > > i am asking you. >> > >> > > Urlich, > > I think the effect you are seeing is due to the FINITE resolution of > the Digital VCO (DDS) in the DPLL. Because the VCO resolution is > finite, the VCO cannot achieve the EXACT same frequency of the input > but can only come very close to it. Since the frequency of the VCO is > not exactly the same as the input, a phase error will accumulate until > the VCO can jump to the next frequency resolution step. I have often > wondered about this myself why this isn't a problem in DPLLs and your > post is the first time I have seen it brought up as a problem. > > You can test to see if this is really the problem by changing the > RESOLUTION of the DDS VCO. If I am correct, the frequency jumps you > are seeing will be equal to the resolutiuon steps of the VCO. also if > you decrease the resolution, the jumps should be larger in magnitude > but lower in repetition frequency. And vice versa as you increase the > VCO resolution the jumps will be smaller in magnitude but more often in > occurance. So you can reduce the magniture of the problem by > increaseing the DDS resolution but as far as I can see there is no why > to reduce the problem to 0. I suppose if you increase the DDS VCO > resolution sufficently, and there is some invevitable phase noise or > jitter in the system, the cyclic error will be burried below the random > phase jitter. > > Thank you for the very interesting question. Please let me know what > you find. > > Mark >