[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnucap] Settling time measurement for underdamped systems
From: |
al davis |
Subject: |
Re: [Help-gnucap] Settling time measurement for underdamped systems |
Date: |
Wed, 15 Jul 2009 19:28:05 -0400 |
User-agent: |
KMail/1.11.4 (Linux/2.6.26-1-amd64; KDE/4.2.4; x86_64; ; ) |
On Wednesday 15 July 2009, Seshadri V wrote:
> I would like to know if there is some way to measure settling
> time of an underdamped system( ringing output) in gnucap.
> AFAIK, there is no direct way measuring the number of ringing
> before the output reaches a steady state output. Because the
> simulator identifies only the first rising edge of the output
> and the oscillations following the first overshoot are not
> identified by the simulator.
First you need to define "settling time".
Then use a combination of measures.
How about: "10% to 90%" ...
the time from the 10% crossing to the last 90% crossing.
Let's assume you know the amplitude before.
For now, let's assume it is a 5 volt pulse.
The voltage starts at 0, and ends up at 5.
The simulation run has a single step.
Do some setup ..
>param startvalue = 0
>param endvalue = 5
Finding the 10% point is easy:
>measure starttime=cross("v(out)" cross={startvalue+(endvalue-startvalue)*0.1}
>rise first)
For the 90% point, you don't know whether the last one is high or low, so try
both:
>measure highendtime = cross("v(out)"
>cross={startvalue+(endvalue-startvalue)*1.1} fall last)
>measure lowendtime = cross("v(out)"
>cross={startvalue+(endvalue-startvalue)*0.9} rise last)
Note the use of the keys "rise" and "fall".
Then take the later of these:
>param endtime={max(highendtime, lowendtime)}
The settling time is the difference:
>param settlingtime = {endtime-starttime}
>eval settlingtime
You may also want to measure the frequency of the ringing:
>measure t2 = cross("v(out)" cross=endvalue before=endtime rise last)
>measure t1 = cross("v(out)" cross=endvalue before=t2 rise last)
>param frequency = {1/(t2-t1)}
>eval frequency
I didn't test this .. there might be mistakes here.
This makes certain assumptions about the waveform.
You could get bogus results if the assumptions are wrong.
Now, a reminder ...
params are evaluated like in a functional language with dynamic scope.
If you think imperitive language, static scope, you may be surprised.