No exact or substring matches. trying for part
PICList
Thread
'[PICLIST] [PIC] dF/dt Gradient slew'
2000\06\27@111720
by
Peter Betts

I hope the title got you interested.
What I'm trying to do it work out the rate of change of an input frequency
with respect to time and if the gradient (dF/dt) is too great I wish to
modify the input signal to slow the rate of change down, effectively slew
the frequency output.
So first of all I think I'm going to use a timer/counter module in counter
mode and clock it using the input frequency signal.
Then have an interrupt to generate a periodic sample interval.
On the interrupt analyse the counter value and store.
Clear the counter.
Then do this over and over again, another 10 times say and then work out the
gradient of the data (the sum of the 10 values divided by 10.... or better
still take 16 counter values and just right shift >>4)
When this value (gradient) goes above a set threshold I could then call a
routine to modify the signal.
Normally the input signal would be fed straight out again untouched but if
the rate of change was too great it would modify the signal and reduce the
frequency slightly. Eventually given time the output frequency would match
the input again but delayed.
rather like switching in a capacitor on a voltage input and slewing the
response if the voltage was above a certain threshold.
Does anybody have any bright ideas about how better to do this or see any
flaws in my plans?
Thanks
Pete
2000\06\27@115226
by
Peter Betts
I forgot to say that the frequency input is a square wave digital pulse
train and I intend to try to use either a 16F84 or ideally just a 12C508
Is a phase accumulator any good for frequency shifting a digital square
wave.
?how to slew the frequency of a digital input signal?
Could I use a delay line or maybe an IIR or FIR to filter the digital
signal?
Pete
> {Original Message removed}
2000\06\27@120854
by
Scott Dattalo

On Tue, 27 Jun 2000, Peter Betts wrote:
> I forgot to say that the frequency input is a square wave digital pulse
> train and I intend to try to use either a 16F84 or ideally just a 12C508
You also forgot to tell us the range in the frequency. Because
>
> Is a phase accumulator any good for frequency shifting a digital square
> wave.
The stability of the frequency of a phase accumulator generated square wave (or
it's jitter, if you will) depends heavily upon the rate at which the phase
accumulator is updated. Higher frequencies generally have more jitter (the
exception is when the frequency output is an exact multiple of the phase
accumulator update rate).
>
> ?how to slew the frequency of a digital input signal?
This could be done easily with a phase accumulator. You can either 1) vary the
rate at which the phase accumulator is updated or 2) vary the phase
accumulator's update variable.
A handwaving observation may point you toward a solution. The phase accumulator
can be viewed as an integrator whose output is frequency. If you want the
derivative of frequency, then the phase accumulator's update is the value you
seek.
e.g.
ph_acc = ph_acc + update_value
freq_output = ph_acc & SOME_MSB
'update_value' is loosely the derivative of freq_output.
The challenges with this will be writing the algorithm efficiently enough to
avoid jitter.
Scott
> Could I use a delay line or maybe an IIR or FIR to filter the digital
> signal?
>
> Pete
>
> > {Original Message removed}
2000\06\27@123829
by
Peter Betts

Thanks Scott,
> You also forgot to tell us the range in the frequency.
The frequency range is relatively low.
0>2kHz with the rapid rate of change predominantly concentrated around
1>2KHz
> This could be done easily with a phase accumulator. You can
> either 1) vary the
> rate at which the phase accumulator is updated or 2) vary the phase
> accumulator's update variable.
> ph_acc = ph_acc + update_value
> freq_output = ph_acc & SOME_MSB
> 'update_value' is loosely the derivative of freq_output.
So first I need to measure the input signal to determine the phase
accumulator update variable.
In simple terms.....this is directly proportional to the delta of the
counter values at each succesive sample interval.
1. read counter value (clocked by the input signal) and store
2. reset counter
3. wait a predetermined period..
4. read counter value again and work out the difference between this value
and the previous stored one.
5. this I can somehow proportionally relate to the true update variable of
the input signal
The output signal is generated from a phase accumulator and controlled by
the "output signal update variable". This normally matches the measured
input update variable.
The input update value can be used to index into a table of "output signal
update variables". i.e. if update rate is above 200 say then I can return
190 (scaled).
The new output signal update variable is now used to modify the output phase
accumulation for the generated output signal.
Eventually the rate of change (the update variable) of the input signal will
reduce and so the input and output will match up again. Eventually being the
slew. and slew being controlled by the scaling I have between input and
output update variables.
Now have I understood this correctly? I'm only slightly confused at the
beginning on how to measure the input signal accumulation update variable.
Is the counter idea going down the right road?
Thanks for your input
Pete
2000\06\27@140431
by
Scott Dattalo

On Tue, 27 Jun 2000, Peter Betts wrote:
> Thanks Scott,
>
> > You also forgot to tell us the range in the frequency.
>
> The frequency range is relatively low.
> 0>2kHz with the rapid rate of change predominantly concentrated around
> 1>2KHz
good!
{Quote hidden}> > This could be done easily with a phase accumulator. You can
> > either 1) vary the
> > rate at which the phase accumulator is updated or 2) vary the phase
> > accumulator's update variable.
>
> > ph_acc = ph_acc + update_value
> > freq_output = ph_acc & SOME_MSB
> > 'update_value' is loosely the derivative of freq_output.
>
>
> So first I need to measure the input signal to determine the phase
> accumulator update variable.
>
> In simple terms.....this is directly proportional to the delta of the
> counter values at each succesive sample interval.
> 1. read counter value (clocked by the input signal) and store
> 2. reset counter
> 3. wait a predetermined period..
> 4. read counter value again and work out the difference between this value
> and the previous stored one.
> 5. this I can somehow proportionally relate to the true update variable of
> the input signal
What you'll need, if you take this approach, is a phase lock loop. I assume that
your input frequency (to which you wish to lock) doesn't vary 'wildly'. While
searching the archives for phase accumulators, you may wish to look for pll's at
the same time.
But, essentially what you'll want to do is synthesize a square wave that has the
same frequency and phase as the one you wish to measure. The simplest algorithm
is something like so:
delta = initial value
pll()
{
if input toggled low to high {
if synthesized square wave is low
delta = delta + pid_value
else
delta = delta  pid_value
}
if input toggled high to low {
if synthesized square wave is low
delta = delta  pid_value
else
delta = delta + pid_value
}
phase_accumulator += delta;
}
The synthesized square wave is obtained by monitoring one of the upper bits in
the phase accumulator.
The idea behind this code is to update the phase accumulator delta whenever the
input square wave changes states. Ideally, you'll want one of the upper bits in
the phase accumulator to exactly track or anticipate when the input changes. If
the input toggles from high to low, then the synthesized square wave needs to do
so as well. So if the synthesized square wave is still high when the real square
wave changes to a low, then that means the phase accumulator is too small. So we
need to speed up the frequency of the synthesized square wave. The amount it is
sped up can be controlled many ways. For example, I sort of alluded to PID
control with the name of the variable being pid_value. However, you could make
it simple P, or proportional, control by measuring how much error there is in
the phase accumulator and by updating the 'delta' variable with a value that's
proportional to it.
The point at which the signals are locked can be ascertained by monitoring the
error between the two. Once the error has reached some predetermined threshold,
then 'delta' will contain the approximate dF/dt you seek. Actually, it'll
contain something more like (delta F/ delta t), where delta t is the time
between each pass through the algorithm.
Scott
{Quote hidden}> The output signal is generated from a phase accumulator and controlled by
> the "output signal update variable". This normally matches the measured
> input update variable.
>
> The input update value can be used to index into a table of "output signal
> update variables". i.e. if update rate is above 200 say then I can return
> 190 (scaled).
>
> The new output signal update variable is now used to modify the output phase
> accumulation for the generated output signal.
>
> Eventually the rate of change (the update variable) of the input signal will
> reduce and so the input and output will match up again. Eventually being the
> slew. and slew being controlled by the scaling I have between input and
> output update variables.
>
> Now have I understood this correctly? I'm only slightly confused at the
> beginning on how to measure the input signal accumulation update variable.
> Is the counter idea going down the right road?
>
> Thanks for your input
>
> Pete
>
2000\06\28@031630
by
Peter Betts

Scott,
(This is a long Email, sorry. I hope you don't get too frustrated reading
it)
I have found and read your Email arichive post relating to phase
accumulators. There is a lot on Phase Accumulation in the archives :)
So as I understand it so far we are using a phase accumulator as a Phase
Locked Loop which is attempting to track/lock onto a static frequency and
match it. Thus the output signal will match the input signal. A rotating
unit circle vector which we are stepping the angle of phase to maintain an
certain output frequency.
Provided the input signal doesn't increase or decrease rapidly the PLL will
keep up with any changes and track it, keeping locked. Now this I understand
is related to the PHASE_DELTA.
If I had a FIXED PHASE_DELTA which I never modified then this would seem to
me to mean we can only lock onto signal frequecnies that are changing at a
rate close to the PHASE_DELTA value. If it changes more slowly than the PLL
can track we will get jitter as the PLL hunts up and down and if it changes
more papidly then we will be unable to track the incoming signal and we will
be producing a slewed output signal.
So the idea (and what seems to be the trickiest bit) is to modify the
PHASE_DELTA according to the rate of change of the incoming signal, this is
the proportional control element (If I understand you correctly)
Therefore on each sample period you look at the accumulator value and if the
signal input has changed state, see how far away from 0 it is. This can then
be used to directly modify/influence the PHASE_DELTA.
Rather than just doing fixed proportional control (i.e. always use 3/4 of
the difference as the PHASE_DELTA) one could use a look up table which
predominantly has the required 3/4 scaling but towards the upper limits has
a greater and greater scaling, 1/2...1/4 etc which would induce an UNLOCKED
condition while the PLL slowly caught up, thus the output is not matched to
the input and thus is SLEWED?
Phew!
Another nice thing is the input signals will not only be in the range
0>2kHz but at the critical time of interest will always be linearly and
positively incrementing. I just need to slow the fastest rate of change down
a bit.
INPUT

.^
/
/
/
/

time >
^
 Frequency
OUTPUT
____
..^^
^^
.
/
/
I will look at your web site for some more clues on PLL, Phase accumulators
and PID.
For the hardware guys the circuit I am trying to emulate or improve upon is
simply this....
(The following diagram is best viewed in plain text, I hope it doesn't WRAP
around)
(signal two)
CONTROL >MONOSTABLE
(0>250Hz) 


_______________
 Reset 
 
INPUT + "4 bit counter"
(0>2kHz)   Q0 Q1 Q2 Q3 
 ________________
    
   _
  _______ \ \
 __________  \0___________
 _ / / 
  GATE _
 _______ \
__________________________________________________________
 OUTPUT SIGNAL
_ /
Four bit counter which clocks up at a rate according to the INPUT. The Q1
and Q2 outputs are NANDed and used as a gateing pulse (GATE) for the OUTPUT.
The OUTPUT is the INPUT & GATE.
With no signal two input, CONTROL, the counter obviously repeatedly counts
from 0>15 and four out of the 16 counts cause the GATE signal to be 0 and
thus turns off the OUTPUT. This is a very crude 4/16 = 3/4 scaling
When signal two (CONTROL) is close in frequency to signal one INPUT it has
the effect of continually resetting the counter and thus GATE is always 1
thus no scaling. BUT the further the two signals get apart the less and less
the reset has an effect and the more the counter does the 3/4 scaling.
CONTROL and INPUT always follow one another, if one increases the other does
too, just at different rates.
This was my analysis of the circuit and hence why I believe I need to slew
the INPUT frequency.
If anybody has a different view then please let me know.
At first I am going to simply build the above in PIC software but eventually
I would like to be able to have more precise control over the scaling and
also it'll be a challenge. Hence the PLL questions.
> ........... I assume that your input frequency (to which you wish to lock)
doesn't vary 'wildly'.
It will vary at a greater and greater rate as time goes by, over a period of
about 4 seconds then it will limit and settle down, it will then decrease at
a very fast rate, about 0.5s (almost brick wall), the decreasing isn't much
of a problem just the inceasing signal gradient.
One solution was to simply scale all the frequencies at the input to
generate the output but that affects normal operation low down in the
frequency range, I want to leave this unaffected and only scale towards the
upper limits where the fault occurs.
Thanks for all you help, very much appreciated.
Pete
ps. I'll search for PLL as well now and hope to find some PIC code examples
:)
More... (looser matching)
 Last day of these posts
 In 2000
, 2001 only
 Today
 New search...