Group Delay in LT SPICE... In fact SPICE tau(w) in general...
Peter Brackett
i.e. group delay defined as:
tau(w) = - d[phi(w)]/dw
Where phi(w) is a transfer function phase angle function.
This is often known as the "point group delay", and is valid wherever phi(w)
has a derivative. Derivatives are "difficult" to calculate and often
computer programs and instrumentation use other algorithms are to
calculate/measure group delay.
In practical instrumentation for measuring group delay the commercial
measuring sets invariably use a *difference* algorithm, derived from a
modulated carrier method, rather than a *differential* algorithm. i.e. they
measure an approximation to group delay often called the "split delay"
tausp(w) ~ delta_phi/delta_w where the small changes indicated by delta here
as delta_phi and delta-w is usually set by taking delta_w in the
neighbourhood of [actually delta-f = 40 Hz ]or so for voice band work.
Such "split delay" measurements are notoriously inaccurate in regions where
the group delay is changing rapidly with frequency, this is particularily
troublesome near group delay peaks where the measured/calculate split delay
and the actual point group delay can deviate greatly!
For many years I have used my own homebrew CAE/CAD programs for group delay
analysis and synthesis, but after a recent interaction with a SPICE
enthusiast, I tried using SPICE for this purpose and got some "funny"
results! In a couple of [admittedly short] investigations I have found
several "anomolies" in group delay outputs from LT Spice.
Does anybody reading the NG know precisely the algorithm(s) by which LT
Spice?
Actually I'm curious about all versions of SPICE's in general, and how they
calculate group delay output?
Also I am curious as to whether any SPICE's produce a *programmable* "split
delay" as well as the "point delay" output. A "split delay" output function
having as an *input* parameter the actual delta_f used by real group delay
measuring sets would be a great benefit to those designing precision group
delay equalizers.
--
Peter
Consultant
Indialantic By-the-Sea, FL.
analog
Peter Brackett wrote:
...
> In a couple of [admittedly short] investigations I have found several
> "anomolies" in group delay outputs from LT Spice.
Could you please elaborate by posting at least one specific example.
Thanks. -- analog
Peter Brackett
[snp]
"analog" <ana...@ieee.org> wrote in message
news:3EED0585...@ieee.org...
[snip]
Yes I can do that.
The recent *problems* I found here were with a fairly high order system [N =
15] which is a bit of a pain to exhibit here on an ASCII news group. I am
now generating some lower order but "tough" group delay problems to
investigate what's happening with the LT Spice group delay output. Maybe
it's just "pilot error".
More later... still...
Meanwhile I'd still like to know... how does LT Spice calculate group delay?
Does it analyze an "adjoint" network to get the exact derivatives, or carry
the derivative formulas throughout the network analysis or, does it do an
numerical approximation to the derivatives? What?
Also I'd like to know how easy it is to get a 40 Hz "split delay" out of LT
Spice? I need to verify a theoretical network result against an actual
network measurement using a W&G LD2 group delay 40 Hz split frequency
measuring set.
I could do this by running an LT Spice phase plot on a linear frequency
scale at 40 Hz intervals and then do the incremental phase subtractions to
get the delta-phi across each 40 Hz interval. But of course I currently
can't get the phase plot numbers out of LT Spice to do this. [If I could
export the actual phase numbers instead of the plot this would be easier. I
certainly don't want to *run* the numbers by hand taking them off using the
cursors and then do the arithmetic by hand, if I could export the phase
versus frequency data to a spread sheet I could compute the "split delay"
graphs myself. Hmmm... perhaps I could use Helmut's utility for this.]
Do any other versions of Spice offer a "split delay" capability? Kevin
Aylward? Others?
Helmut Sennewald
news:bcj6bf$vau$1...@slb5.atl.mindspring.net...
> ...
> I could do this by running an LT Spice phase plot on a linear frequency
> scale at 40 Hz intervals and then do the incremental phase subtractions to
> get the delta-phi across each 40 Hz interval. But of course I currently
> can't get the phase plot numbers out of LT Spice to do this. [If I could
> export the actual phase numbers instead of the plot this would be easier.
I
> certainly don't want to *run* the numbers by hand taking them off using
the
> cursors and then do the arithmetic by hand, if I could export the phase
> versus frequency data to a spread sheet I could compute the "split delay"
> graphs myself. Hmmm... perhaps I could use Helmut's utility for this.]
>
Hello Peter,
LTSPICE always produces a .raw output file containing the phasors(real,imag)
of all nodes of your simulations. You could specify in the control
panel to get an ASCII readable output. This file format requires
additional effort to filter out your signal.
To make it easier to export the data, there is an utility program
LTSPUTIL.EXE which can filter out the signals you want from any LTSPICE
*.raw file and it can output an ASCII file in a easy readable table format.
The LTSPUTIL.EXE can be downloaded from the LTSPICE-Yahoo-group.
http://groups.yahoo.com/group/LTspice/files/Util/
Please use version 2.0.
Best Regards
Helmut
PS: I have written this program LTSPUTIL.EXE. If you have eany problem
with it, please let me know.
Kevin Aylward
Doubt it. The basic Spice2/Spice3 code does not have group delay at all,
so its a vendor add on. I do have it implemented in SS but its just a
simple derivative of basic phase method.
You can save text data in SS by using the "\File\Save Waveforms in Data
text files" menu. This will save data as a simple column list that you
can load into Excel etc.
Kevin Aylward
sa...@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.
Peter Brackett
Thanks for the reply.
[snip]
> Doubt it. The basic Spice2/Spice3 code does not have group delay at all,
> so its a vendor add on. I do have it implemented in SS but its just a
> simple derivative of basic phase method.
[snip]
Is the group delay calculation that you have implemented in Super Spice a
numerical derivative or a derivative from an analytic formula for group
delay?
[snip]
> You can save text data in SS by using the "\File\Save Waveforms in Data
> text files" menu. This will save data as a simple column list that you
> can load into Excel etc.
>
> Kevin Aylward
[snip]
Thanks again.
analog
Peter Brackett, analog Peter Brackett wrote:
>>> In a couple of [admittedly short] investigations I have found
>>> several "anomolies" in group delay outputs from LT Spice.
>> ...
>> Could you please elaborate by posting at least one specific example.
...
> Yes I can do that.
>
> The recent *problems* I found here were with a fairly high order
> system [N = 15] which is a bit of a pain to exhibit here on an ASCII
> news group.
No need to post a schematic in ascii drawing format. Just open the
LTspice "asc" file with Wordpad, Notepad or other ascii text editor,
copy the entire contents and paste it (as ascii text) as part of a
post to this newsgroup. Do not include it as an attachment. LTspice
schematic files are saved as a plain text list of high level drawing
commands.
> I am now generating some lower order but "tough" group delay
> problems to investigate what's happening with the LT Spice group
> delay output. Maybe it's just "pilot error".
>
> More later... still...
>
> Meanwhile I'd still like to know... how does LT Spice calculate group
> delay?
I don't know (and doubt that anyone besides Mike Engelhardt is privy
to that information). But that won't stop me from hazarding a guess -
which is that group delay is only calculated on the simulation data by
the waveform display module as a post process.
> Does it analyze an "adjoint" network to get the exact derivatives,
> or carry the derivative formulas throughout the network analysis or,
> does it do an numerical approximation to the derivatives? What?
Take this with a grain of salt, but my guess is that for an ac
analysis, at each increment of frequency, LTspice saves complex
numbers (real and imaginary pairs) for each branch current and node
voltage in the circuit's matrix representation. Since the ac
excitation sources are ideal and noiseless, basic numerical
difference techniques can be used to accurately calculate group delay.
> Also I'd like to know how easy it is to get a 40 Hz "split delay" out
> of LT Spice? I need to verify a theoretical network result against
> an actual network measurement using a W&G LD2 group delay 40 Hz split
> frequency measuring set.
What do you mean by "split delay" in this context?
> I could do this by running an LT Spice phase plot on a linear
> frequency scale at 40 Hz intervals and then do the incremental
> phase subtractions to get the delta-phi across each 40 Hz interval.
Why is simple group delay inadequate for directly checking the
circuit's response to the same end without the intervening
complications? Perhaps the answer to the "split delay" question
will make this clear.
> But of course I currently can't get the phase plot numbers out of
> LT Spice to do this. [If I could export the actual phase numbers
> instead of the plot this would be easier. I certainly don't want to
> *run* the numbers by hand taking them off using the cursors and then
> do the arithmetic by hand, if I could export the phase versus
> frequency data to a spread sheet I could compute the "split delay"
> graphs myself. Hmmm... perhaps I could use Helmut's utility for this.
That's what it's there for.
Mike was planning to integrate this capability into LTspice some day
soon. Maybe this will spurn him on to do it some day sooner.
By the way, from the LTspice control panel (compression pane) you
can set the output format to get ascii raw files, but the data is
just an enumerated table of complex number pairs for each frequency
point. It will have data for every node and branch unless you use a
.save statement (spice text - see the help file) to instruct LTspice
to only save what interests you.
analog
PS: Tried to post this last night, but my cable internet service has
been randomly intermittent ever since my old ISP was swallowed by
Comcast. I bet they add insult to injury by soon upping their prices
for their new "improved" service.
Mike Engelhardt
> ..Does anybody reading the NG know precisely the algorithm(s)
> by which LT Spice?..
LTspice uses finite differences of the output data with
phase unraveling. You can go to Plot Settings=>Mark Data
Points and see the group delay is plotted between the
unprocessed output data. The integrity of the method
requires you to request enough data points.
The phase will be unraveling even inside the finite
difference. If you have a 180 degree shift to either
side of a simple notch, you can still see a continuous
group delay. Phase unraveling for group delay does
not depend on any data outside of the two points for
the finite difference calculation.
--Mike
Kevin Aylward
> Hi Kevin:
>
> Thanks for the reply.
>
> [snip]
>> Doubt it. The basic Spice2/Spice3 code does not have group delay at
>> all, so its a vendor add on. I do have it implemented in SS but its
>> just a simple derivative of basic phase method.
> [snip]
>
> Is the group delay calculation that you have implemented in Super
> Spice a numerical derivative or a derivative from an analytic formula
> for group delay?
Computed from the phase data.
How can it possible be an analytic formula? Spice is a *numerical*
method of solving equations. It only outputs data points, not formulas.
Ok, there is an exception in pole-zero analysis...but this is still only
a curve fit.
Peter Brackett
[snip]
> Computed from the phase data.
>
> How can it possible be an analytic formula? Spice is a *numerical*
> method of solving equations. It only outputs data points, not formulas.
> Ok, there is an exception in pole-zero analysis...but this is still only
> a curve fit.
>
> Kevin Aylward
[snip]
Thanks for that further feedback.
I do realize that SPICE is a numerical integrator of simultaneous
differential equations.
However the differential equations being solved numerically by SPICE's
numerical quadratures [Trapezoidal, Gear, etc...] are analytic, i.e. the
nodal equations, the Ebers-Moll [Gummel Poon], Schichman-Hodges, etc... are
all analytic formulas. Spice is not numerically integrating a previously
computed data set it is integrating a set of equations expressed
analytically. Which is what most SPICE's do for group delay.
If I understand your explanation, SPICE's that present group delay outputs
do not calculate the group delay from an *exact* analytic formula rather
they "estimate" group delay as a numerical derivative taken from phase
function differences produced as a result of numerically integrating
analytic differential equations. Of course this method of numerical
differentiation from a table is subject to errors, sometimes quite large.
Since group delay computations done in this way [Calculated numerically as
differences of phase outputs divided by differences of frequency] it is
only fair that the SPICE authors inform the users of the group delay functon
what the group delay algorithm in use is and to make appropriate caveats as
to how the calculated group delay can become grossly in error under certain
conditions, where SPICE is otherwise working well!
It would also be of interest for the user to know the exact split frequency
in use during the calculation to help the user to estimate the probable
errors in the group delay, i.e. the delta f being used by SPICE to calculate
the group delay. The knowledge of the "split-f" in use is especially
necessary if one is to compare the SPICE group delay to group delay
measurements made using standard laboratory group delay measuring equipment.
Kevin as you know, group delay is a simple analytic function and can be
expressed explicitly as a formula in terms of element values and the
independent variables. There is really no need to make a somewhat dodgy
numerical approximation to this function when it can be computed exactly.
As you know, for a lumped linear time invariant network the group delay is a
rational polynomial which is far simpler to evaluate than the phase
function, i.e. group delay simply does not require the use of trancendentals
[trigonometry]. In order to calculate group delay during a nodal network
analysis all one has to do in the algorithms is to carry along the analytic
formulas for the derivatives of branch impedances d[Z(p)]/dp and admittances
d[Y(p)]/dp with respect to frequency p, and then substiute the numerical
values into the formulas at the end of the analysis to evaluate tau(w) =
d[phi(w)]/dw in terms of the dZ/dp and dY/dp formulas which are simple
rational polynomial functions.
Another method of getting these branch derivatives with respect to p, but
which takes a bit more work, is to simultaneously analyze both the network
at hand and its' adjoint network and then apply a well known network theorem
to get the derivatives of the branches with respect to frequency and
subsequently the *exact* formula for group delay.
I have always wondered why these simple technique were not used in SPICEs to
calculate an accurate error free analytic group delay. Lots of network
analysis programs that predate SPICE certainly did that. Perhaps it was
because the original SPICE authors at Berkely were not interested in group
delay, or perhaps did not understand what is could be used for or how to
actually calculate it.
In any case... every version of SPICE that I have ever encountered, when
they do offer group delay, they have done a terrible job of calculating it.
And... I am ranting here since I ran into it again with LT Spice with one of
my clients again just a few days ago.
For this reason, I continue to maintain my own "homebrew" network analysis
programs wherein I carry the differential formulas all the way through so
that the group delay is calculated directly from an analytic formula and is
therefore "exact" as opposed to an error prone numerical derivative.
I find it exasperating when a client uses SPICE to check/analyze one of my
network designs and makes the claim that my group delay is wrong because it
doesn't agree with SPICE! Heh, heh... I always tell them, these days SPICE
is the bible, but... not for group delay!
If users ever find that SPICE group delay output does not agree with some
other analysis or measurement I am here to tell you that invariably the
SPICE is wrong.
SPICE and group delay... Caveat Emptor!
Peter Brackett
[snip]
> No need to post a schematic in ascii drawing format. Just open the
> LTspice "asc" file with Wordpad, Notepad or other ascii text editor,
> copy the entire contents and paste it (as ascii text) as part of a
> post to this newsgroup. Do not include it as an attachment. LTspice
> schematic files are saved as a plain text list of high level drawing
> commands.
>[snip]
Thanks for that input. When I get my simple example I'll do that.
[snip]
> I don't know (and doubt that anyone besides Mike Engelhardt is privy
> to that information). But that won't stop me from hazarding a guess -
> which is that group delay is only calculated on the simulation data by
> the waveform display module as a post process.
[snip]
Yes I believe that to be so, and it seems that Kevin Aylward has confirmed
that as well. This is a pretty *dodgy* way to calculate group delay since
it is highly error prone, as are all numerical diffentiation techiques, near
critical points like passband edges and loss poles, etc...
[snip]
> Take this with a grain of salt, but my guess is that for an ac
> analysis, at each increment of frequency, LTspice saves complex
> numbers (real and imaginary pairs) for each branch current and node
> voltage in the circuit's matrix representation. Since the ac
> excitation sources are ideal and noiseless, basic numerical
> difference techniques can be used to accurately calculate group delay.
[snip]
I take exception to the word "accurately" in the above. Anyone who has
experience with numerical differentiation "knows" that it is problematic at
best... if there is any other way to compute a function then do not use
numerical differentiation, it is *very* noisy especially at critical points.
[snip]
> > Also I'd like to know how easy it is to get a 40 Hz "split delay" out
> > of LT Spice? I need to verify a theoretical network result against
> > an actual network measurement using a W&G LD2 group delay 40 Hz split
> > frequency measuring set.
>
> What do you mean by "split delay" in this context?
[snip]
Group delay for a lumped linear time invariant network is a well behaved
analytic function,
actually a simple rational polynomial, which can be evaluated exactly. When
group delay
is being approximated by a numerical approximate derivative as SPICE does,
i.e.:
tau(f) ~ [(phi2 -phi1)/(2*pi*f2 - 2*pi*f1)]
then the difference off frequency in the denominator (w2 - w1) is called the
split frequency.
Actually all commercial group delay measuring sets such as the W&G LD2,
etc... measure
split delay and not the exact group delay and they do this using a modulated
carrier with
the two sidebands spaced at the split frequency separation, in the case of
the LD2 it is 40 Hz.
Clearly if one is designing a precision group delay where the synthesis and
design is done
analytically, but the measurement of the results, are done using split delay
techniques on a
commercial delay measuring set, then one needs a network analysis program
that can
produce both the analytic group delay as well as the split group delay, and
the split group
delay program output should match the split f of the measuring set. And so
it is desirable
that the split f be programmable by the user of the analysis program so that
its' outputs
can match the group delay measuring set. Not all group delay measuring sets
use the same
split f. i.e. There is no "standard" split f.
[snip]
> Why is simple group delay inadequate for directly checking the
> circuit's response to the same end without the intervening
> complications? Perhaps the answer to the "split delay" question
> will make this clear.
[snip]
Simple! To synthesize a "required" group delay, for instance to synthesize
a desired
time waveforms, one needs to be to calculate the exact analytic group delay
in the synthesis and
design procedure. Then one has to analyze the result with a split delay
analysis in order
to check the production units against the results of testing with a split
delay measuring
set. The two delays [the analytic point delay and the numerical approximate
split delay]
are invariably different, especially near critical points, and so one needs
both.
Unfortunately most SPICE's generate only one of these, i.e. the split delay
and indeed
does a very bad job at this, because the user never knows what the split is
so that
he may correlate with the measuring set.
Thus SPICE is essentially useless as s tool for group delay design and
analysis.
[snip]
> > frequency data to a spread sheet I could compute the "split delay"
> > graphs myself. Hmmm... perhaps I could use Helmut's utility for this.
>
> That's what it's there for.
>
> Mike was planning to integrate this capability into LTspice some day
> soon. Maybe this will spurn him on to do it some day sooner.
[snip]
That's nice, I'll get that utility.
Thanks for your interest and help.
Peter Brackett
[snip]
> The integrity of the method
> requires you to request enough data points.
[snip]
Nice of you to mention that fact. It seems that many users are unaware of
the need
to request enough data points and often do not know how to estimate how many
data points they do need. And... most of all, many are not aware of the
need in
some cases to accurately set the frequency difference between data points to
match
the split frequency of delay measuring sets.
[snip]
> The phase will be unraveling even inside the finite
> difference. If you have a 180 degree shift to either
> side of a simple notch, you can still see a continuous
> group delay. Phase unraveling for group delay does
> not depend on any data outside of the two points for
> the finite difference calculation.
[snip]
I have seen "glitches" in LT SPICE's group delay outputs, those glitches are
not bad though.
I wanted to be sure just how the delay is computed and now I understand that
it is computed
from the analysis data points, i.e. post processing in the graphical
routines.
I believe the following is how you calculate the group delay.
From the listed table of phase angles at each frequency point, i.e. phi1 at
f1, phi2 at f2, etc...
LT SPICE computes the difference quotient -(phi2 - phi1)/(2*pi*f2 - 2*pi*f1)
as an approximation
to the exact group delay tau = - d(phi(w)/dw
With a log frequency scale the delta f = (f2 - f1) will actually be changing
with frequency which is
somewhat disconcerting since a constant delta f is what is usually desired.
This can be amelioriated
by using a linear scale, but its' not handy for analzying accurately across
several octaves/decades.
Also it would be useful to allow the user to specify the delta f and number
of points rather than or at
least as an alternative to the frequency interval end points and number of
points, this way the user
could more easily match the SPICE group delay output to that of standard
laboratory group delay
measuring sets.
I know that group delay is a somewhat arcane subject for most users, but
there are a few of us
who care about the details of group delay analysis and would like to see the
various versions of
SPICE bring themselves up to scratch and produce practical and useful group
delay outputs.
Sorry for the "rant".
And... thanks for responding, I appreciate it. And I am a grateful user of
LT SPICE and Linear
Products. I use LT Spice a lot and I am impressed with most all aspects of
it with the exception
of group delay.
Thanks again!
--
Peter
Consultant
Indialantic By-the-Sea, FL.
>
> --Mike
>
>
Charles DH Williams
<ab...@ix.netcom.com> wrote:
> If I understand your explanation, SPICE's that present group delay outputs
> do not calculate the group delay from an *exact* analytic formula rather
> they "estimate" group delay as a numerical derivative taken from phase
> function differences produced as a result of numerically integrating
> analytic differential equations. Of course this method of numerical
> differentiation from a table is subject to errors, sometimes quite large.
A couple of comments:
The idealised devices installed in spice are themselves approximations, as
are the parameter sets used to model particular devices, and things like
parasitic capacitances are notoriously rough and ready in a lot of cases.
Even if one constructs an 'analytic' formula in one of the ways you
propose, evaluating it will be subject to significant numerical errors.
I don't think that most people would '"estimate" group delay as a
numerical derivative taken from phase function differences produced as a
result of numerically integrating analytic differential equations.' I
believe that most people would use the obvious method which is to use the
output from an ac analysis (and a phase-unwrapping function) to produce a
phase vs frequency plot. It is then very easy to produce an estimate of
d(phi)/df and use the second derivative to sound warning bells if the
truncation error renders the results unreliable. This method has the
advantage that it will work when there are transmission line elements in
the circuit, which would seem to be a pretty common requirement in cases
where group delay matters.
> I have always wondered why these simple technique were not used in SPICEs to
> calculate an accurate error free analytic group delay. Lots of network
> analysis programs that predate SPICE certainly did that.
Spice was not intended to be a network analysis program in that sense, its
primary purpose was facilitate IC design.
> Perhaps it was because the original SPICE authors at Berkely were not
> interested in group delay,
Possibly.
> or perhaps did not understand what is could be used for or how to
> actually calculate it.
You are joking.
> For this reason, I continue to maintain my own "homebrew" network analysis
> programs wherein I carry the differential formulas all the way through so
> that the group delay is calculated directly from an analytic formula and is
> therefore "exact" as opposed to an error prone numerical derivative.
It's 'exact' as long as long as you can prove there are no bugs in your
programs, and the formulae are evaluated using methods that produce
guaranteed error bounds.
> I find it exasperating when a client uses SPICE to check/analyze one of my
> network designs and makes the claim that my group delay is wrong because it
> doesn't agree with SPICE! Heh, heh... I always tell them, these days SPICE
> is the bible, but... not for group delay!
I'd be very interested to see netlist that illustrates such a case,
perhaps you could post one.
> If users ever find that SPICE group delay output does not agree with some
> other analysis or measurement I am here to tell you that invariably the
> SPICE is wrong.
Not many people here would claim that spice is infallible, its just a tool
that needs a certain amount of skill to use.
Charles.
Mike Engelhardt
> I believe the following is how you calculate the group delay.
>
> From the listed table of phase angles at each frequency point, i.e. phi1 at
> f1, phi2 at f2, etc...
> LT SPICE computes the difference quotient -(phi2 - phi1)/(2*pi*f2 - 2*pi*f1)
> as an approximation to the exact group delay tau = - d(phi(w)/dw
Yes, it's a finite difference method, but the algorithm is insensitive
even to phase reversal. For example, this notch has discontinuous
phase to either side of the notch. The phase actually is discontinuous.
Phase unwrap can't make it look smooth. But the group delay is
continuous and is plotted as such:
*
V1 N001 0 AC 1.
R4 X N001 60K
C4 N001 N003 .1u
C5 X N002 .1u
C6 N002 N003 .1u
R5 0 N003 5K
R6 N002 0 5K
.ac oct 100 100 300
.probe V([x])
.end
> With a log frequency scale the delta f = (f2 - f1) will actually be changing
> with frequency which is somewhat disconcerting since a constant delta f is
> what is usually desired.
I don't think a constant delta frequency is of any particular great benefit,
but the integrity of the group delay computation method does requires
you to request enough data points. After you have enough points, it
should plot correctly.
-- Mike
Peter Brackett
[snip]
> I don't think a constant delta frequency is of any particular great
benefit,
> but the integrity of the group delay computation method does requires
> you to request enough data points. After you have enough points, it
> should plot correctly.
>
> -- Mike
[snip]
The particular great benefit of a constant delta frequency, *is* the direct
correlation of SPICE outputs with the data produced by several long
established commercial group delay measuing sets.
By the way, in the community of those who design group delay equalizers,
what your SPICE program is calculating is conventionally named "Split
Frequency Delay" *not* "Group Delay.
The term "Group Delay" is invariably reserved for the true analytic
derivative function which is always used in the approximation and synthesis
steps of delay equalizer design.
"Split Delay" is acutally used during lab testing and computer analysis and
it is invariably based upon a uniform frequency split even when a
logarithmic scale is used.
Since only a few users of SPICE are really interested in these needs, I
don't believe that SPICE, or LT SPICE in particular, needs to change
anything other than "documentation" and labeling to help users who wish to
make use of that function.
In that regard, I believe it would be more accurate and less confusing to
rename the output in LT Spice from "Group Delay" to "Split Frequency Group
Delay" followed by an asterisk with a note attached somewhere. It would
also be useful to place a one paragraph note in the help file.
For example, on the LT Spice dialog box that allows a radio button selection
of either Group Delay or Phase I suggest you replace the label "Group Delay"
with the label "Split Frequency Group Delay *".
Then down below in the dialog box, or maybe in the status area, put another
asterisk with the following annotation, or something like it, in small font:
* Split Frequency Group Delay is calculated numerically from phase
information by a finite difference quotient. The denominator frequency
difference or split frequency being set by the frequency analysis parameters
input by the user, i.e. frequency end points and number of points. The user
should carefully choose the end points and number of points as necessary to
ensure any particular desired frequency split. For logarithmic frequency
analysis the split frequency interval will always be non-uniform.
Perhaps with those minor changes and caveats I am sure that group delay
novices can be saved some problems.
Thanks for a "great program", I love LT Spice.
Mike Engelhardt
> ...The particular great benefit of a constant delta frequency, *is* the
direct
> correlation of SPICE outputs with the data produced by several long
> established commercial group delay measuring sets...
But I don't think the measuring instruments can use as small of difference
in frequency as a simulator and perform the finite difference math to 15
digit
accuracy. Whereas an instrument is stuck with split frequency group delay
and many billions of times less accurate finite difference math, the
simulator
readily approaches the analytical group delay. In fact, it can do an
exceeding
good job at that as the netlist I posted has a discontinuous phase but a
continuous group delay and LTspice has no trouble plotting that result.
--Mike
Peter Brackett
[snip]
> But I don't think the measuring instruments can use as small of difference
> in frequency as a simulator and perform the finite difference math to 15
> digit
> accuracy. Whereas an instrument is stuck with split frequency group delay
> and many billions of times less accurate finite difference math, the
> simulator
> readily approaches the analytical group delay. In fact, it can do an
> exceeding
> good job at that as the netlist I posted has a discontinuous phase but a
> continuous group delay and LTspice has no trouble plotting that result.
>
> --Mike
[snip]
You are missing the whole point!
Delay measuring sets are the *only* way of measuring the group delay of
actual
physical realizations!
And so... to ensure that designs have been implemented correctly the
laboratory/production
measurements on prototypes/production units obtained from the delay test
sets need to be
compared to a computer generated [comparable] data set. The only way to do
this is to set
the split delay frequency separation of the computer generated data to the
same split as the
laboratory delay test set uses.
This can be done currently by appropriately chosing the frequency end points
and the number
of data points with a linear scale in SPICE, but it cannot be done at all
when using the logarthmic
frequency scale. Conventional network/filter analysis programs allowed the
user to specify
the "split frequency" separation as an input parameter which could be set to
the value used
by the delay measuring set the user wished to use, and to use that split
frequency for delay
calculations regardless of linear or logarithmic frequency axis.
BTW... delay calculations in or near notches is not important. Especially
in "filters" where
the signals in the notches are actually being rejected by the filter and of
no interest to the
user. You could even turn off the delay calculations when near a notch for
that reason. No
one would notice since no one cares.
The *important* areas for group delay accuracy are near the peaks of group
delay, which
in filters appear near the passband edges within the passbands at
frequencies of great interest
to designers. The higher the rate of cutoff in the transition band from
pass band to stop band
the peakier the group delay at the passband edge becomes. And that is the
area where the
numerical difference quotients become most sensitive and subject to error!
Group delay designers need very accurate analytic group delay calculations
at these passband
edge points where the group delay peaks up, and when they go to the lab to
verify their
designs they need to be able to get computer generated split delay
calculations to compare
with the actual measurements produced by the laboratory delay measuring sets
at their
particular frequency split.
As you can probably now understand, these practical requirements renders
most versions
of SPICE impractical or even useless for those of us who have to design
precision group
delay functions, especially for circuits having high cutoff rate transition
bands.
Any help you could for us would be most welcome!
Especially an understanding of the need for and difference between "split
frequency delay"
and analytic "point group delay".
Mike Engelhardt
> This can be done currently by appropriately chosing the frequency
> end points and the number of data points with a linear scale in
> SPICE, but it cannot be done at all when using the logarthmic
> frequency scale.
LTspice plots the group delay albeit computed with finite
differences. There's a trade off between too small of a
delta frequency giving numerically noisy delta Phi/delta Freq
and too large of a delta frequency not having a constant group
delay over the range so the average group delay over the
delta frequency is not constant over the region that the
finite difference is performed. A logarithmic frequency
sweep is usually the best choice here if you want to get
as close as possible to plotting the true group delay with
minimal numerical errors except for circuits using delay
lines.
But I don't think I know what you're complaining about.
You already know how to "set the split delay frequency
separation of the computer generated data to the same
split as the laboratory delay test set uses". And I am
sure you're smart enough to figure all this stuff out
yourself.
--Mike
Peter Brackett
[snip]
> But I don't think I know what you're complaining about.
> You already know how to "set the split delay frequency
> separation of the computer generated data to the same
> split as the laboratory delay test set uses". And I am
> sure you're smart enough to figure all this stuff out
> yourself.
>
> --Mike
[snip]
Don't get me wrong, I love LT Spice, and again "Thanks"!
No I still don't believe that you fully understand/appreciate what I am
asking for.
Yes can figure all this out myself, and I have several ways of accomplishing
what I
need. Some of these require my own homebrew programs, for approximation,
synthesis, design and analysis of group delay functons. *I* have to do this
cuz
designing high precision group delay equalizers is one way that I earn my
living.
Unfortunaely for me, my customers often like to analyze and test my
precision
delay equalizer designs using their own programs and laboratory equipment.
Invariably they use SPICE to analyze delay equalizer designs and their SPICE
results often do not match either their lab test equipment or my own
*exact* analysis!
Then ensues a long discussion on why SPICE is *no good* for group delay
analysis!
They stop arguing only because my designs actually work, even though SPICE
says
they don't! Heh, heh...
Mike, as a consultant, I do like to use SPICE [LT Spice in particular] for
analysis of
analog circuits. I often use Linear's great analog products in my designs
as well. I use a
lot of Linear's Op Amps in my high precision all-pass group delay equalizer
designs.
For this work, I had to develop one of the few programs available for high
precision group
delay analog and digital approximation and synthesis.
I only posted my "complaint" tosuggest that, with a minor amount of simple
data processing
effort, outside the program's internal network analysis loops, ya'll could
create a very useful
"nice to have" feature in LT Spice. I feel that y'all could modify LT
Spice's data processing
output section before one of the next releases to enable users to specify
split delay calculation
in more detail so as to allow accurate and close correlation to group delay
tests sets.
i.e.
Allow the user to specify the split frequency, call it delta (Hz), as an
input parameter for
both linear and logarithmic frequency steps. As a default value I would
suggest that
you use delta = 40 Hz because at least two commercial delay test sets that I
have use
have have a built in 40 Hz split. Other group delay test sets use other
split frequencies,
and this is not standardized so you need to have a default and alsow let the
user specify
the delta.
This new feature would not require any great intellectual work for ya'll,
it's just a manipulation
of the front and back end of the program's data processing functions. These
minor changes
would entail running the frequency analysis at two extra points for each
frequency point when
in group delay mode, i.e. when running group delay analysis it would be
three points instead of
one for each frequency of analysis.
One frequency for the primary analysis [of dB, magnitude, phase, etc.] at
each frequency
point f, then additionally at two more points at a user specified frequency
separation of one
half the split frequency on either side of the main frequency at (f +
delta/2) and (f - delta/2)
to get the phases phi(f+delta/2) and phi(f-delta/2) at those side frequency
points and then
have the program calculate and present the split delay data as the
difference quotient:
tau split(f) = [phi(f-delta/2) - phi(f+delta/2)]/delta
That's it, that's all, simple eh?
"Just do it!"
That, and... heh, heh... stop calling "split delay" "group delay", it just
ain't right!
Mike... There's *no charge* for the advice, and keep up the good work!
Best,
Kevin Aylward
> Mike:
>
> [snip]
{snip}
>
> tau split(f) = [phi(f-delta/2) - phi(f+delta/2)]/delta
>
> That's it, that's all, simple eh?
>
> "Just do it!"
>
> That, and... heh, heh... stop calling "split delay" "group delay", it
> just ain't right!
>
> Mike... There's *no charge* for the advice, and keep up the good work!
You know mate, I simply don't know what your really on about. Run about
10,000 points per decade, at 0.01% reltol, and it it will be, to all
intents and purposes, nuts on. End of story.
Helmut Sennewald
> Mike:
>
> [snip]
>
> > But I don't think I know what you're complaining about.
> > You already know how to "set the split delay frequency
> > separation of the computer generated data to the same
> > split as the laboratory delay test set uses". And I am
> > sure you're smart enough to figure all this stuff out
> > yourself.
> >
> > --Mike
> [snip]
>
> Don't get me wrong, I love LT Spice, and again "Thanks"!
>
> No I still don't believe that you fully understand/appreciate what I am
> asking for.
>
Hello Peter,
I just have read a chapter about group delay measurement from
"Wandel and Goltermann". They indeed have(had?) analyzers which use
this modulation method with 40Hz you also mentioned.
But finally this is nothing more than measuremet the phase difference
40Hz apart. Tg=delta_phase/40Hz
The most probably mistake you can make here is sweeping too fast.
If you want do that 40Hz spacing in SPICE, eg. from 50Hz to 20kHz,
then simply run a ".AC lin 501 30 20030".
It calculates the phase with 40Hz step size at 30Hz, 70Hz, 110Hz, ...
and from that the group delay with Tg=delta_phase/40Hz for the mean
frequencies 50Hz, 90Hz and so on.
Logaritmic scales could be done with precalculated frequencies
.AC LIST (freq1-20Hz), (freq1+20Hz), (freq2-20Hz), (freq2+20Hz) ....
Ok, here is eventually some post processing necessary if you donn't
like the inbetween calculated group delay points.
I am still waiting for a circuit from you where SPICE has failed.
Please provide a circit that we really can discuss about SPICE flaws
regarding group delay.
To Mike,
please don't change the word group delay in LTSPICE to any other
like "split frequency delay". This would lead to a lot of confusion.
Best Regards
Helmut
Peter Brackett
[snip]
> You know mate, I simply don't know what your really on about. Run about
> 10,000 points per decade, at 0.01% reltol, and it it will be, to all
> intents and purposes, nuts on. End of story.
>
> Kevin Aylward
> sa...@anasoft.co.uk
> http://www.anasoft.co.uk
> SuperSpice, a very affordable Mixed-Mode
> Windows Simulator with Schematic Capture,
> Waveform Display, FFT's and Filter Design.
[snip]
WRONG!
Heh, heh... damm poser!
Yes indeed Kevin, it will be "nuts on" and approach the point analytic group
delay as closely as
desired if you do that, but that does nothing to match the actual laboratory
measurements of split
delay produced by common garden variety delay measuring sets!
Let me ask...
Have you ever actually built a network/equalizer and attempted to measure
it's group delay
to verify a design or done a producton test on a group delay equalizer? If
so what was
the application, frequency range and PAR of the signals?
Have you ever operated, owned, seen, a group delay measuring set?
If so, please supply manufacturer, model number, split frequency in use,
frequency display type!
Sigh...
Stupid SPICE jocks... I'm only trying to help ya'll, but instead ya'll make
me feel like the one eyed
man in the land of the blind!
You could take my advice and greatly improve your SuperSpice program with
*very* little work
to make it much easier for delay equalizer folks to use, but instead... you
just keep on saying,
Wah, wah, wah... I don't understand what you'r talking about!
It's just as I suspected about all ya'll SPICE programming jockeys, ya'll
understand GUI's but
understand nothing about network analysis and network functions.
Think, man... some of us do practical things and develop products, not just
build GUI's for decades
old computer programs written by graduate students!
What?
Jim Thompson
<ab...@ix.netcom.com> wrote:
[snip]
>Sigh...
>
>Stupid SPICE jocks... I'm only trying to help ya'll, but instead ya'll make
>me feel like the one eyed
>man in the land of the blind!
>
>You could take my advice and greatly improve your SuperSpice program with
>*very* little work
>to make it much easier for delay equalizer folks to use, but instead... you
>just keep on saying,
>Wah, wah, wah... I don't understand what you'r talking about!
>
>It's just as I suspected about all ya'll SPICE programming jockeys, ya'll
>understand GUI's but
>understand nothing about network analysis and network functions.
>
>Think, man... some of us do practical things and develop products, not just
>build GUI's for decades
>old computer programs written by graduate students!
>
>What?
Peter, PSpice does offer group delay in Probe by simply using
"VG(node-name)" in an AC analysis.
I've not used it so I have no idea of its accuracy in PSpice. Can you
suggest a test circuit and I'll give it a whirl?
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| Jim-T@analog_innovations.com Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
For proper E-mail replies SWAP "-" and "_"
Get Lolita Out of Debt... Add Three Inches to Your Mortgage!
Peter Brackett
[snip]
> To Mike,
> please don't change the word group delay in LTSPICE to any other
> like "split frequency delay". This would lead to a lot of confusion.
>
> Best Regards
> Helmut
>[snip]
Heh, heh... :-)
Helmut my friend, what LT Spice calculates and calls "group delay" is a
sham, those results should be called "unspecified split frequency delay".
It definitely is *NOT* "group delay.
"The Group Delay" is an analytic functon calculated at a single frequency
point w = 2*pi*f, not a noisy numerical derivative obtained by difference
methods over a split frequency spread, i.e.
"Group Delay" is:
taugr(w) = d[phi(w)]/dw [Ever wonder what that is used for?]
"Split frequency delay" is what delay measuring sets acutally measure in
practice:
tausp(w) = [phi(w + wsplit/2) - phi(w - wsplit/2)]/[(w + wsplit/2) - (w -
wsplit/2)] [What that is used for?]
"Phase Delay" is "faster than light" expressed as:
tauph(w) = phi(w)/w [What is the meaning of this and how would it be used
in design and analysis?]
and, the Signal Front Delay is:
tausfr(w) = {lim w -> inf} phi(w)/w [Hmm, I wonder if this could be used by
seismologists, unerwater acousticians?]
Hey, man! Wake up. Opportunity is calling here!
Calling a potentially noisy and unspecified difference quotient
approximation to group delay the "real deal" based upon arbitrary split
frequencies is just plain WRONG!
And furthermore such methods do not produce results that can be corroborated
or compared *exactly* with lab measurements! Isn't that the "raison d'etre"
of computer anlaysis programs, to provide a solid link between theoretical
and practical results.
As Yogi Bera once said, "In theory, theory and practice are the same, but in
practice they are different!"
Well, ya'll, here you have postings from a real practicioner of the art of
design, synthesis and manufacture of group delay equalizers offering
suggestions as to how your theoretical compter assists might be improved and
made more useful to practicioners and all ya'll produce is critiques of the
practicioner's suggestions. I guess progress on SPICE is at a standstill!
Sigh!
Me? I simply don't wait for ya'll to awaken from your stupor!
For group delay work, I use network analysis programs, other than SPICE, for
practical design and test, simply because SPICE delay results are
inaccurate, unreliable and user UN-friendly.
With about a day's work by a comptent programmer, who knows the outside
parametes of any version of SPICE could modified the frequency analysis
parameters to produce useable and user friendly delay function outputs.
I'd like to see all of them...
Group Delay [probably impossible with current SPICE the way it is!], user
specified Split Frequency Delay [Easy to do], Phase Delay [Easy to do],
Signal Front Delay [Easy to do]!
Why has this not been done by those like Kevin Aylward? Simple! No
application domain know how! These folks have never been asked to design a
time domain waveform/signal to specific requirements, they have never had to
design a delay equalizer to correct the defects in a filter, etc... etc...
But then again, it's a small market and not worth a couple of man-days of
programming effort to do things right, since few users/customers know or
care about group delay and it's uses.
I'm glad because for those who do care, such confusion creates opportunities
for consultants to ply their trade.
:-)
Keep those SPICE improvements coming...
BTW... I rate LT Spice *above* Super Spice, simply because LT Spice is a
great product and it is FREE, while Super Spice which I have never used, is
not FREE.
Kudos to Mike and Linear a great team.
Sorry Kevin!
Mike Engelhardt
> Helmut my friend, what LT Spice calculates and calls
> "group delay" is a sham, those results should be
> called "unspecified split frequency delay".
This is misleading. LTspice certainly does plot the group
delay. It's fair to compute derivatives by finite differences
especially with the nature of data from a small signal AC
analysis. Calculus. Accuracy of a ppm are routine. To say
it doesn't is numberically exactly the same as saying it's
not okay to draw lines between the data points of the Bode
graph where the solution isn't computed. LTspice even gets
the group delay right when there is a true phase discontinuity
in the middle of the region of the finite difference. You
just need to take the responsibility to specify enough
points/octave. The operation is apparent with a bit of
experience.
Comparing this group delay to measured data can indeed be
problematic. You will have to study the instruments manual
and learn how to set apertures and such. As you continue with
simulation and analytical methods, you will find many
quantities of extreme utility in understanding and designing
circuits that can be computed much more easily than measured,
if possible to measure at all. One example is LTspice's
ability to plot group delay right through a notch where the
signal vanishes and the phase is discontinuous.
--Mike
Kevin Aylward
> Kevin:
>
> [snip]
>> You know mate, I simply don't know what your really on about. Run
>> about 10,000 points per decade, at 0.01% reltol, and it it will be,
>> to all intents and purposes, nuts on. End of story.
>>
>
> WRONG!
>
> Heh, heh... damm poser!
>
> Yes indeed Kevin, it will be "nuts on" and approach the point
> analytic group delay as closely as
> desired if you do that, but that does nothing to match the actual
> laboratory measurements of split
> delay produced by common garden variety delay measuring sets!
>
> Let me ask...
>
> Have you ever actually built a network/equalizer and attempted to
> measure it's group delay
> to verify a design or done a producton test on a group delay
> equalizer? If so what was
> the application, frequency range and PAR of the signals?
>
> Have you ever operated, owned, seen, a group delay measuring set?
>
You mean your measuring equipment is poor, such that it cannot measure
accurately what is *defined* as group delay. We had a daft thread on a
similar vain where the audio nuts redefine accuracy by throwing away
some of the measured errors.
> If so, please supply manufacturer, model number, split frequency in
> use, frequency display type!
>
> Sigh...
>
> Stupid SPICE jocks... I'm only trying to help ya'll, but instead
> ya'll make me feel like the one eyed
> man in the land of the blind!
>
> You could take my advice and greatly improve your SuperSpice program
> with *very* little work
> to make it much easier for delay equalizer folks to use, but
> instead... you just keep on saying,
But as you claimed previously, there are only about 20 in the field, so
why bother.
> Wah, wah, wah... I don't understand what you'r talking about!
That's because your trying to redefine accepted ee terms, so your
talking nonsense. Group Delay is defined by the derivative of phase. Its
not debatable. A numerical derivative, of sufficient accuracy, is
completely equivalent to this definition. The fact that typical
measuring equipment may use some other arbitrary method to determine GD,
is no justification for you suggesting that GD in spice should be
renamed. It is the measuring method that is incorrect, or an
approximation, not the spice method.
>
> It's just as I suspected about all ya'll SPICE programming jockeys,
> ya'll understand GUI's but
> understand nothing about network analysis and network functions.
>
> Think, man... some of us do practical things and develop products,
> not just build GUI's for decades
> old computer programs written by graduate students!
Ahmmm. Einstein, as did many others, done major work before he even
gained his PhD.
>
I add new, useful non-gui specific features, but gui driven, all the
time to SS, e.g. http://www.anasoft.co.uk/DeviceDesigner.html
Kevin Aylward
> Peter,
>
>> Helmut my friend, what LT Spice calculates and calls
>> "group delay" is a sham, those results should be
>> called "unspecified split frequency delay".
>
> This is misleading. LTspice certainly does plot the group
> delay. It's fair to compute derivatives by finite differences
> especially with the nature of data from a small signal AC
> analysis. Calculus. Accuracy of a ppm are routine. To say
> it doesn't is numberically exactly the same as saying it's
> not okay to draw lines between the data points of the Bode
> graph where the solution isn't computed.
One of the rare times I actually agree with you Mike.
Helmut Sennewald
> Helmut:
>
> [snip]
> > To Mike,
> > please don't change the word group delay in LTSPICE to any other
> > like "split frequency delay". This would lead to a lot of confusion.
> >
> > Best Regards
> > Helmut
> >[snip]
>
> Heh, heh... :-)
>
> Helmut my friend, what LT Spice calculates and calls "group delay" is a
> sham, those results should be called "unspecified split frequency delay".
>
> It definitely is *NOT* "group delay.
>
> "The Group Delay" is an analytic functon calculated at a single frequency
> point w = 2*pi*f, not a noisy numerical derivative obtained by difference
> methods over a split frequency spread, i.e.
Hello Peter,
any .AC analysis of group delay can be more than three decades less
noisy then any real measurement. Of course, you have to set enough
data points.
I am still waiting for an example from you where SPICE has failed.
This would be the only way to convince us that we all are wrong.
You could either provide a SPICE netlist or the .asc file.
Both are pure ASCII and could be contained in your next posting.
We all want learn something new, but now it's time for an example.
Best Regards
Helmut
Jens Tingleff
Hash: SHA1
Peter Brackett wrote:
> Q: re group delay calculations.
>
[...]
>
> Actually I'm curious about all versions of SPICE's in general, and how
> they calculate group delay output?
Well, not a Spice-like program, but the filter analysis/optimisation program
LCP2 by H Gaunholt[1] of the Technical University of Denmark uses proper
derivative calculations.
LCP2 is a goold old program (with emphasis on both), without a user-friendly
drag-and-drool interface[2] but with a really superb number-crunching
engine.
It warms the cockles of my heart to see output like this (the first from 200
points frequency analysis - log spaced - and the second from 20 points over
the same range)
: FREQ/RPS MAGN MAGN/DB PHASE/DEG DELAY/SEC
: 2.00000E-02 4.95635E-01 -6.0968 7.0029 -5.84086E+00
: 2.04659E-02 4.95438E-01 -6.1002 7.1586 -5.82245E+00
: 2.09426E-02 4.95233E-01 -6.1038 7.3173 -5.80326E+00
: 2.14304E-02 4.95019E-01 -6.1076 7.4793 -5.78325E+00
: FREQ/RPS MAGN MAGN/DB PHASE/DEG DELAY/SEC
: 2.00000E-02 4.95635E-01 -6.0968 7.0029 -5.84086E+00
: 2.51785E-02 4.93248E-01 -6.1387 8.7038 -5.61764E+00
: 3.16979E-02 4.89695E-01 -6.2015 10.7418 -5.28578E+00
Regards
Jens
[1] http://www.oersted.dtu.dk/personal/hg/
[2] ;-) ;-) ;-)
- --
Key ID 0x09723C12, j.tin...@ieee.org/jens_t...@yahoo.com
Analogue filtering / 5GHz RLAN / Mdk Linux / odds and ends
http://www.imaginet.fr/~jensting/ +44 1223 211 585
"Your mother was a hamster and your father smelled of elderberries" M.
Python
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+8qp/imJs3AlyPBIRAmvHAJ9DDb0wrPHz2XO2EMuphesaIeIsngCeNRUC
ehL004/28/F9WZdlRQugzqk=
=xZfv
-----END PGP SIGNATURE-----
Kevin Aylward
> Helmut:
>
> [snip]
>> To Mike,
>> please don't change the word group delay in LTSPICE to any other
>> like "split frequency delay". This would lead to a lot of confusion.
>>
>> Best Regards
>> Helmut
>> [snip]
>
> Heh, heh... :-)
>
> Helmut my friend, what LT Spice calculates and calls "group delay" is
> a sham, those results should be called "unspecified split frequency
> delay".
>
> It definitely is *NOT* "group delay.
Yes it is.
>
> "The Group Delay" is an analytic functon calculated at a single
> frequency point w = 2*pi*f, not a noisy numerical derivative obtained
> by difference methods over a split frequency spread, i.e.
>
> "Group Delay" is:
>
> taugr(w) = d[phi(w)]/dw [Ever wonder what that is used for?]
>
> "Split frequency delay" is what delay measuring sets acutally measure
> in practice:
>
> tausp(w) = [phi(w + wsplit/2) - phi(w - wsplit/2)]/[(w + wsplit/2) -
> (w - wsplit/2)] [What that is used for?]
>
> "Phase Delay" is "faster than light" expressed as:
>
So can Group Delay be faster than light. Unfortunately, some uninitiated
individuals believe that GD is the speed of the message. It isn't,
although in many cases it is a good approximation.
> tauph(w) = phi(w)/w [What is the meaning of this and how would it be
> used in design and analysis?]
>
> and, the Signal Front Delay is:
>
> tausfr(w) = {lim w -> inf} phi(w)/w [Hmm, I wonder if this could be
> used by seismologists, unerwater acousticians?]
>
> Hey, man! Wake up. Opportunity is calling here!
>
> Calling a potentially noisy and unspecified difference quotient
> approximation to group delay the "real deal" based upon arbitrary
> split frequencies is just plain WRONG!
Not at all. Its a well known and accepted mathematical approximation,
that in the limit as df->0, is the real derivative of the function.
It does not mater what df is, as long as it ->zero in the limit. The
derivative is a unique limit that is independent of approach, by
definition. You may know a tad about electrical engineering, but
apparently your maths sucks.
>
> And furthermore such methods do not produce results that can be
> corroborated or compared *exactly* with lab measurements!
So, your lab measurements are wrong.
> Isn't that
> the "raison d'etre" of computer anlaysis programs, to provide a solid
> link between theoretical and practical results.
>
> As Yogi Bera once said, "In theory, theory and practice are the same,
> but in practice they are different!"
>
> Well, ya'll, here you have postings from a real practicioner of the
> art of design, synthesis and manufacture of group delay equalizers
> offering suggestions as to how your theoretical compter assists might
> be improved and made more useful to practicioners and all ya'll
> produce is critiques of the practicioner's suggestions. I guess
> progress on SPICE is at a standstill! Sigh!
>
> Me? I simply don't wait for ya'll to awaken from your stupor!
>
> For group delay work, I use network analysis programs, other than
> SPICE, for practical design and test, simply because SPICE delay
> results are inaccurate, unreliable and user UN-friendly.
>
No, your measurements are inaccurate. Spice results are usually quite
reproducible.
Kevin Aylward
salesE...@anasoft.co.uk
Peter Brackett
[snip]
> I add new, useful non-gui specific features, but gui driven, all the
> time to SS, e.g. http://www.anasoft.co.uk/DeviceDesigner.html
>
> Kevin Aylward
[snip]
For some good information on group delay I suggest your read the material on
group delay in:
Adel. S. Sedra and Peter O. Brackett, "Filter Theory and Design: Active and
Passive", Matrix, Portland OR, 1978.
Then *listen* to a potential customer, add the capability for user specified
split delay analysis output to Super Spice!
What was it John Cleese once said on a Faulty Tower's episode, "Never kill a
customer!"
Damned SPICE jockeys!
--
Peter
Consultant
Indialantic By-the-Sea, FL.
Peter Brackett
Hello, nice to see a fellow group delay jockey on this Newsgroup.
[snip]
> It warms the cockles of my heart to see output like this (the first from
200
> points frequency analysis - log spaced - and the second from 20 points
over
> the same range)
>
> : FREQ/RPS MAGN MAGN/DB PHASE/DEG DELAY/SEC
> : 2.00000E-02 4.95635E-01 -6.0968 7.0029 -5.84086E+00
> : 2.04659E-02 4.95438E-01 -6.1002 7.1586 -5.82245E+00
> : 2.09426E-02 4.95233E-01 -6.1038 7.3173 -5.80326E+00
> : 2.14304E-02 4.95019E-01 -6.1076 7.4793 -5.78325E+00
>
> : FREQ/RPS MAGN MAGN/DB PHASE/DEG DELAY/SEC
> : 2.00000E-02 4.95635E-01 -6.0968 7.0029 -5.84086E+00
> : 2.51785E-02 4.93248E-01 -6.1387 8.7038 -5.61764E+00
> : 3.16979E-02 4.89695E-01 -6.2015 10.7418 -5.28578E+00
>
> Regards
>
> Jens
[snip]
Point well made.
I have several programs which do it "right" as well. No need to use SPICE
for
group delay, eh?
Regards,
Peter Brackett
Helmut:
[snip]
> We all want learn something new, but now it's time for an example.
>
> Best Regards
> Helmut
[snip]
Try this with a 40 Hz "split" and compare with a point analysis and see how
awkward/difficult it becomes to do the comparison analysis near the peaks.
---
For group delay analysis
RS N002 N001 1
L1 N003 N002 0.626m
C2 N004 N003 29.49µ
L3 N004 N005 63.79µ
C3 N005 0 1.2687m
C4 N004 0 361.8µ
C5 N006 N004 35.75µ
L5 N004 N006 231.3µ
C8 0 Out 31.41µ
L7 0 Out 54.71µ
RL Out 0 1.888
VS N001 0 AC 1.0 0.0
C6 Out N006 37.99µ
.ac lin 500 400 2400
.backanno
.end
---
Peter Brackett
I posted a netlist for an example in answer to Helmut's post a little
further down the thread.
--
Peter
Consultant
Indialantic By-the-Sea, FL
"Jim Thompson" <Jim-T@analog_innovations.com> wrote in message
news:t7k4fvoehh4j9m8th...@4ax.com...
Peter Brackett
Let me make it simple.
If changing the number and density of the frequency analysis points in your
network analysis program changes the values of your so-called group delay
output at any frequency point then... IT IS NOT GROUP DELAY!
True group delay can be evaluated at a single frequency point!
What group delay result will you get from SPICE if you specify analysis at a
single frequency point? Zip, zilch, nada!
What ya'll are computing is called "split frequency delay" not "group
delay"!
And... to add insult to injury ya'll don't even let the user specify the
split! What?
Come on, get with the program!
Just do it!
Regards,
--
Peter
Consultant
Indialantic By-the-Sea, FL.
"Kevin Aylward" <ke...@anasoft.co.uk> wrote in message
news:hFxIa.984$j21....@newsfep1-win.server.ntli.net...
Peter Brackett
[snip]
> No, your measurements are inaccurate. Spice results are usually quite
> reproducible.
>
> Kevin Aylward
[snip]
Balderdash!
Spice is a computer program, measurements are "real".
Not only that, heh, heh...
but Spice cannot even evaluate the "theoretical" group delay.
The theoretical group delay can be evaluated at a single frequency point.
Submit a single frequency point to your Spice program and see what happens?
I have a network analyis program here on this disk to which I can submit a
single frequency and get a true group delay result in return. What? You's
can't do that?
"In theory, theory and practice are the same, but in practice they are
different." -- Yogi Berra
You'r in over your head man. Spice computes only "split frequency delay".
Period end of story!
:-)
Kevin Aylward
> Kevin:
>
> [snip]
>> I add new, useful non-gui specific features, but gui driven, all the
>> time to SS, e.g. http://www.anasoft.co.uk/DeviceDesigner.html
>>
>> Kevin Aylward
> [snip]
>
> For some good information on group delay I suggest your read the
> material on group delay in:
>
> Adel. S. Sedra and Peter O. Brackett, "Filter Theory and Design:
> Active and Passive", Matrix, Portland OR, 1978.
>
> Then *listen* to a potential customer, add the capability for user
> specified split delay analysis output to Super Spice!
>
> What was it John Cleese once said on a Faulty Tower's episode, "Never
> kill a customer!"
>
Theres a new hotel/restaurant in, Manchester I believe, styled on Faulty
Towers, customer insults and all. Apparently everyone thinks its great.
Kevin Aylward
salesE...@anasoft.co.uk
Kevin Aylward
> Kevin:
>
> [snip]
>> No, your measurements are inaccurate. Spice results are usually quite
>> reproducible.
>>
>> Kevin Aylward
> [snip]
>
> Balderdash!
>
> Spice is a computer program, measurements are "real".
>
> Not only that, heh, heh...
>
> but Spice cannot even evaluate the "theoretical" group delay.
>
It can calculate it as accurately as you please.
> The theoretical group delay can be evaluated at a single frequency
> point.
>
So, and your point would be?
> Submit a single frequency point to your Spice program and see what
> happens?
You obviously don't know the basics of calculus. Differentiation is a
limiting process. See my other post.
Kevin Aylward
> Mike, Kevin, Helmut et al:
>
>
> "Kevin Aylward" <ke...@anasoft.co.uk> wrote in message
> news:hFxIa.984$j21....@newsfep1-win.server.ntli.net...
>> Mike Engelhardt wrote:
>>> Peter,
>>>
>>>> Helmut my friend, what LT Spice calculates and calls
>>>> "group delay" is a sham, those results should be
>>>> called "unspecified split frequency delay".
>>>
>>> This is misleading. LTspice certainly does plot the group
>>> delay. It's fair to compute derivatives by finite differences
>>> especially with the nature of data from a small signal AC
>>> analysis. Calculus. Accuracy of a ppm are routine. To say
>>> it doesn't is numberically exactly the same as saying it's
>>> not okay to draw lines between the data points of the Bode
>>> graph where the solution isn't computed.
>>
>
> Let me make it simple.
>
> If changing the number and density of the frequency analysis points
> in your network analysis program changes the values of your so-called
> group delay output at any frequency point then... IT IS NOT GROUP
> DELAY!
In the limit df->0 the results will be the same. That is, keep reducing
the frequency step size until the last value of GD is the same as the
next one with some prescribed accuracy.
>
> True group delay can be evaluated at a single frequency point!
>
That correct. However, one looks at the *limit* as (G(f+df) - G(f))/df
as df->0
> What group delay result will you get from SPICE if you specify
> analysis at a single frequency point? Zip, zilch, nada!
>
> What ya'll are computing is called "split frequency delay" not "group
> delay"!
>
No its called a numerical differentiation of phase, and in the limit, is
identical to GD.
> And... to add insult to injury ya'll don't even let the user specify
> the split! What?
You don't need to, as I have stated the derivative is a *unique* value
independent of approach. You only have to specify some df < delta such
that dG < epsilon (dG = G(f) - L). Look up a maths text on calculus. GD
is simple a trivial application of differentiation. Chose a small enough
value, and its as close as one pleases to the true derivative.
Kevin Aylward
salesE...@anasoft.co.uk
Helmut Sennewald
> Helmut:
>
> Helmut:
>
> [snip]
> > We all want learn something new, but now it's time for an example.
> >
> > Best Regards
> > Helmut
> [snip]
>
> Try this with a 40 Hz "split" and compare with a point analysis and see
how
> awkward/difficult it becomes to do the comparison analysis near the peaks.
>
Hello Peter,
indeed it has very steep notches and thus we will need a high resolution in
the frequency domain. It is all ok, if we reduce the frequency steps below
0.2Hz in our simulation.
.AC LIN 20001 400 2400 * (0.1Hz resolution)
The results are very consistent for any number of steps above 10000,
and I am shure they are equal to your calculations.
Summary:
(LT)SPICE has calculated it correctly. It is just the user who can cause
wrong calculations if he doesn't set enough frequency resolution.
May be someone can give an easy estimation of the maximum frequency
step allowed in .AC analysis for group delay, depending on the steepest
dPhi/dFreq.
Best Regards
Helmut
PS: I have attached the equivalent LTSPICE schematic file.
> ---
> For group delay analysis
> RS N002 N001 1
> L1 N003 N002 0.626m
> C2 N004 N003 29.49µ
> L3 N004 N005 63.79µ
> C3 N005 0 1.2687m
> C4 N004 0 361.8µ
> C5 N006 N004 35.75µ
> L5 N004 N006 231.3µ
> C8 0 Out 31.41µ
> L7 0 Out 54.71µ
> RL Out 0 1.888
> VS N001 0 AC 1.0 0.0
> C6 Out N006 37.99µ
> .ac lin 500 400 2400
> .backanno
> .end
> ---
>
>
LTSPICE schematic file "group.asc"
Version 4
SHEET 1 1276 680
WIRE 64 128 -48 128
WIRE -48 128 -48 224
WIRE -48 304 -48 448
WIRE 144 128 192 128
WIRE 272 128 320 128
WIRE 448 128 448 192
WIRE 576 128 576 240
WIRE 656 176 688 176
WIRE 656 176 656 128
WIRE 656 80 688 80
WIRE 752 176 816 176
WIRE 816 176 816 128
WIRE 816 80 768 80
WIRE 576 304 576 448
WIRE 448 384 448 448
WIRE 448 448 -48 448
WIRE 448 272 448 320
WIRE 384 128 448 128
WIRE 448 128 576 128
WIRE 656 128 656 80
WIRE 816 128 864 128
WIRE 816 128 816 80
WIRE 928 128 976 128
WIRE 976 128 1072 128
WIRE 976 240 976 128
WIRE 1184 128 1184 240
WIRE 1072 240 1072 128
WIRE 976 304 976 448
WIRE 1184 448 1184 320
WIRE 1072 320 1072 448
WIRE 976 448 576 448
WIRE -48 480 -48 448
WIRE 576 128 656 128
WIRE 576 448 448 448
WIRE 1072 128 1152 128
WIRE 1072 448 976 448
WIRE 1072 448 1184 448
WIRE 1152 128 1184 128
FLAG 1152 128 Out
FLAG -48 480 0
SYMBOL voltage -48 208 R0
WINDOW 123 24 132 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName VS
SYMATTR Value ""
SYMATTR Value2 AC 1
SYMBOL res 48 144 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName RS
SYMATTR Value 1
SYMBOL ind 176 144 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 5 56 VBottom 0
SYMATTR InstName L1
SYMATTR Value 0.626m
SYMBOL cap 320 144 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C2
SYMATTR Value 29.49µ
SYMBOL ind 432 176 R0
SYMATTR InstName L3
SYMATTR Value 63.79µ
SYMBOL cap 432 320 R0
SYMATTR InstName C3
SYMATTR Value 1.2687m
SYMBOL cap 560 240 R0
SYMATTR InstName C4
SYMATTR Value 361.8µ
SYMBOL cap 688 192 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C5
SYMATTR Value 35.75µ
SYMBOL ind 672 96 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 5 56 VBottom 0
SYMATTR InstName L5
SYMATTR Value 231.3µ
SYMBOL cap 864 144 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C6
SYMATTR Value 37.99µ
SYMBOL cap 960 240 R0
SYMATTR InstName C8
SYMATTR Value 31.41µ
SYMBOL ind 1056 224 R0
SYMATTR InstName L7
SYMATTR Value 54.71µ
SYMBOL res 1168 224 R0
SYMATTR InstName RL
SYMATTR Value 1.888
TEXT -32 24 Left 0 !.ac lin 20001 400 2400
TEXT -32 -16 Left 0 ;Use >10000 steps in .AC analysis for group delay.
TEXT -32 -56 Left 0 ;Cauer Band Pass
Chuck Harris
delay, or spice, I believe the following applies:
The problem here comes about when you misunderstand what
spice is doing, and what your test equipment is measuring.
Spice wants to give a result that is created out of an
effectively infinite number of points on a curve that
represents the result.
The test equipment cannot do this, so it uses analog means
to measure and calculate the result at a sparse number of
distinct points on the curve. For example, every 40Hz.
To force spice to only make its calculations using such a
sparse number of points will result in an error function
that is too high to allow the result to be believable.
Your df has to approach zero, not be equal to 40Hz.
So, to get an accurate result, you must let spice calculate
with an effectively infinite number of points on the curve,
and then if you want to compare your results with that of
your test set, you must only look at the results every 40Hz.
-Chuck
(by effectively infinite, I mean allow df to get small
enough so that the error approaches zero)
Helmut Sennewald
news:bcv3l8$a95$02$1...@news.t-online.com...
Hello to all LTSPICE users,
please switch "off" the inductor damping feature of LTSPICE. The selection
box is within the Control Panel. This can be important, if you have
to simulate resonators(e.g. crystals) with very high Qs of many thousands.
Accidentally you have to do that after each restart of LTSPICE.
I would like to have a command line in the schematic for that.
Control Panel -> Hacks -> click off "Supply a min. inductor damping if no
Rpar is given"
I haven't seen an obvious difference in the given example, but the there
is an impact on high Q resonators.
So it is more secure to switch this feature "off" for this circuit too.
Best Regards
Helmut
Mike Engelhardt
Also, you can replace the line
.ac lin 20001 400 2400
with
.ac lin {steps} 400 2400
.step param steps list 4000 8000 16000 32000 64000
to demonstrate the group delay converge to within a
part per million.
Indeed LTspice computes group delay. Also
you see that it has the hardest time around
the notches -- the test case I was quick to
point out -- but it gets those eventually, too.
BTW, this is good circuit to use a log sweep.
That will give better overall group delay
accuracy with fewer total points needed to
compute.
--Mike
"Helmut Sennewald" <HelmutS...@t-online.de> wrote in message news:bcv3l8$a95$02$1...@news.t-online.com...
Mike Engelhardt
> >Stupid SPICE jocks... I'm only trying to help ya'll, but instead ya'll make
> >me feel like the one eyed
> >man in the land of the blind!
> >
> >You could take my advice and greatly improve your SuperSpice program with
> >*very* little work
> >to make it much easier for delay equalizer folks to use, but instead... you
> >just keep on saying,
> >Wah, wah, wah... I don't understand what you'r talking about!
> >
> >It's just as I suspected about all ya'll SPICE programming jockeys, ya'll
> >understand GUI's but
> >understand nothing about network analysis and network functions.
> >
> >Think, man... some of us do practical things and develop products, not just
> >build GUI's for decades
> >old computer programs written by graduate students!
> >
> >What?
>
> Peter, PSpice does offer group delay in Probe by simply using
> "VG(node-name)" in an AC analysis.
>
> I've not used it so I have no idea of its accuracy in PSpice. Can you
> suggest a test circuit and I'll give it a whirl?
It looks like PSpice makes an error around notches. LTspice runs
it correctly, but PSpice gives the wrong answer. Here's the deck
I used:
* D:\xp\group.asc
Rnix N006 0 1G
VS N001 0 AC 1
RS N001 N002 1
L1 N002 N003 0.626m; Rser=0
C2 N003 N004 29.49u
L3 N004 N006 63.79u; Rser=0
C3 N006 0 1.2687m
C4 N004 0 361.8u
C5 N004 N005 35.75u
L5 N004 N005 231.3u; Rser=0
C6 N005 Out 37.99u
C8 Out 0 31.41u
L7 Out 0 54.71u; Rser=0
RL Out 0 1.888
.ac lin 8K 400 2400
.probe
.end
Note that to get LTspice to interpret the circuit identically, either uncomment
the Rser=0 or set that as the default in the Control Panel. Also, Rnix is
inserted in the circuit because PSpice thought it needed the .op point. LTspice
recognizes it as a linear circuit and skips the .op, since the behavior at DC is
never requested.
The error around the notches is a common one for SPICE programs. I've
just dealt enough with group delay that I fixed the error in LTspice.
Best regards all round.
--Mike
Jim Thompson
wrote:
>Jim,
>
[snip]
Mike, I'm not qualified to comment so I've sent your remarks to PSpice
Support.
Mike Engelhardt
Thanks, Jim, but perhaps I spoke too soon. Actually, the
more I think about it, PSpice's method is okay. Either way
I wouldn't worry about it. LTspice is saying that the delay
is equal up to the notch as approached from both sides. So
it just draws the line straight through(,though it actually
does this by computing the slope had there been no phase
reversal). The exact mathematical answer for the circuit
is to look like in LTspice plots it but with the point on the
number line at the notch frequency down off at negative
infinity group delay. The PSpice plots have a whole region
where the finite difference is performed going down to
never-never land, but to it's credit, the area is right.
If you use physical circuits, like a little Rser in the inductors,
the notch isn't infinite and the phase is continuous. Then both
LTspice and PSpice will plot the same result, which for me is
ultimately enough.
I prefer the LTspice way of handling the singularity, but I just
realized there's one advantage to PSpice's. That being if you
take the limit by slowing reducing the Rser, then the PSpice
limit for Rser will look more correct taken in that light. The
LTspice looks more correct if start with Lser=0 and computer the
delay ever closer to the notch frequency. Since the value is
the same no matter from which direction it's taken, I used that
picture.
The other point about PSpice refusing to compute the circuit
without Rnix is an old issue. That's a common problem that
various SPICE's make. The best solution for the simulator
is to skip the .op because the circuit is linear so the .op
solution has no affect on the .ac solution. All node voltages
are defined at every frequency requested. LTspice determines
the circuit is linear by inspection and skips the .op, thereby
eliminating an artificial numerical problem.
What it is.
--Mike
Helmut Sennewald
> Helmut:
>
> Helmut:
>
> [snip]
> > We all want learn something new, but now it's time for an example.
> >
> > Best Regards
> > Helmut
> [snip]
>
> Try this with a 40 Hz "split" and compare with a point analysis and see
how
> awkward/difficult it becomes to do the comparison analysis near the peaks.
>
Hello Peter,
indeed it has very steep notches and thus we will need a high resolution in
the frequency domain.
I said in one of my previous posting:
It is all ok, if we reduce the frequency steps below
0.2Hz in our simulation.
.AC LIN 20001 400 2400 * (0.1Hz resolution)
The results are very consistent for any number of steps above 10000,
and I am shure they are equal to your calculations.
Summary:
(LT)SPICE has calculated it correctly. It is just the user who can
cause
wrong calculations if he doesn't set enough frequency resolution.
May be someone can give an easy estimation of the maximum frequency
step allowed in .AC analysis for group delay, depending on the steepest
dPhi/dFreq.
This is still true if we have some series resistance (1mOhm?) for all
the inductors and capacitors. I accidentally forgot to set Rser=0 in LTSPICE
when I simulated first. This has to be done manually for everey inductor and
capacitor. It is not necessary for PSPICE. If we look now the phase of Vout,
we can see a phase jump of 180 degree. LTSPICE ignores these phase jumps and
replaces the normal calculation (deltaPhi/deltaFreq) of the group delay by
the average from the group delay of the previous and next point. This is
different from what PSPICE does.
I am in doubt that this was a good decision how LTSPICE handles this case.
PSPICE is here more straight forward.
I have attached the corrected version of your circuit with all the Rser=0.
Do you have the analytical result at the notches?
I am interested in it.
Best Regards
Helmut
> ---
> For group delay analysis
> RS N002 N001 1
> L1 N003 N002 0.626m
> C2 N004 N003 29.49µ
> L3 N004 N005 63.79µ
> C3 N005 0 1.2687m
> C4 N004 0 361.8µ
> C5 N006 N004 35.75µ
> L5 N004 N006 231.3µ
> C8 0 Out 31.41µ
> L7 0 Out 54.71µ
> RL Out 0 1.888
> VS N001 0 AC 1.0 0.0
> C6 Out N006 37.99µ
> .ac lin 500 400 2400
> .backanno
> .end
> ---
>
>
LTSPICE-file(name.asc)
Corrected version with Rser=0.
SYMATTR Value2 AC 1
SYMATTR InstName VS
SYMATTR Value ""
SYMBOL res 48 144 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName RS
SYMATTR Value 1
SYMBOL ind 176 144 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 5 56 VBottom 0
SYMATTR InstName L1
SYMATTR Value 0.626m
SYMATTR SpiceLine Rser=0
SYMBOL cap 320 144 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C2
SYMATTR Value 29.49µ
SYMATTR SpiceLine Rser=0
SYMBOL ind 432 176 R0
SYMATTR InstName L3
SYMATTR Value 63.79µ
SYMATTR SpiceLine Rser=0
SYMBOL cap 432 320 R0
SYMATTR InstName C3
SYMATTR Value 1.2687m
SYMATTR SpiceLine Rser=0
SYMBOL cap 560 240 R0
SYMATTR InstName C4
SYMATTR Value 361.8µ
SYMATTR SpiceLine Rser=0
SYMBOL cap 688 192 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C5
SYMATTR Value 35.75µ
SYMATTR SpiceLine Rser=0
SYMBOL ind 672 96 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 5 56 VBottom 0
SYMATTR InstName L5
SYMATTR Value 231.3µ
SYMATTR SpiceLine Rser=0
SYMBOL cap 864 144 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C6
SYMATTR Value 37.99µ
SYMATTR SpiceLine Rser=0
SYMBOL cap 960 240 R0
SYMATTR InstName C8
SYMATTR Value 31.41µ
SYMATTR SpiceLine Rser=0
SYMBOL ind 1056 224 R0
SYMATTR InstName L7
SYMATTR Value 54.71µ
SYMATTR SpiceLine Rser=0
SYMBOL res 1168 224 R0
SYMATTR InstName RL
SYMATTR Value 1.888
TEXT -24 -184 Left 0 !.ac lin 20001 400 2400
TEXT -32 -16 Left 0 ;Use >10000 steps in .AC analysis for group delay.
TEXT -32 -56 Left 0 ;Cauer Band Pass
TEXT 544 -16 Left 0 ;Switch off "Inductor damping"
TEXT -32 -144 Left 0 ;.ac lin {steps} 400 2400\n.step param steps list 4000
8000 16000 32000 64000
Jim Thompson
wrote:
>Jim,
Mike, I just downloaded the latest LTSpice... gain and phase look
identical with PSpice. How do you display group delay in LTSpice?
Mike Engelhardt
> Mike, I just downloaded the latest LTSpice... gain and phase look
> identical with PSpice. How do you display group delay in LTSpice?
Move the mouse to the right of the right axis. The mouse cursor
turns into a vertical ruler trying to indicate that you're pointing
at that axis' attributes. Left mouse click. Then check the group
delay radio button under representation. All three axes attributes
are edited in a similar mouse syntax.
--Mike
Jim Thompson
wrote:
>Jim,
OK. Looks good... PSpice and LTSpice are in complete agreement.
Peter Brackett
[snip]
> Thanks, Jim, but perhaps I spoke too soon. Actually, the
> more I think about it, PSpice's method is okay. Either way
> I wouldn't worry about it. LTspice is saying that the delay
> is equal up to the notch as approached from both sides. So
> it just draws the line straight through(,though it actually
> does this by computing the slope had there been no phase
> reversal). The exact mathematical answer for the circuit
> is to look like in LTspice plots it but with the point on the
> number line at the notch frequency down off at negative
> infinity group delay. The PSpice plots have a whole region
> where the finite difference is performed going down to
> never-never land, but to it's credit, the area is right.
[snip]
Heh, heh... interesting notches. What is it about notches?
y'all are still working on the WRONG problem.
Forget about the notches! Notches are "black holes"!
Read my posts! No one cares about the delay in a notch!
What happens, anything that happens for that matter, in a notche's
black hole is of no interest to anyone except perhaps a Phsicist or a
Mathematician.
Effects that happen way down in a notch are not in the realm of
practical results! Jeesh... go figure?
The areas of importance in group delay analysis are at or
near delay peaks which are generally no where near notches.
What LT SPICE customers who evaluate group delay need is
an easy and accurate evaluation of the exact group delay at each
and every frequency point just like the other parameters
that are output by LT SPICE like magnitude, phase, dB's, etc...
I'll try to explain my current application.
The particular network I shared with ya'll in another post is a passive LC
filter
from an ultra low noise sensor application I've been working with a client
on.
The passive LC network I posted sits behind a very low noise sensor and
feeds
an ultra low noise Op Amp [Currently an LT-1128, en = 3nV/rtHz, enk=2.3Hz,
in=1.3pA/rtHz ink=100Hz whose LT Spice model I currently have a problem
with, but Mike... that's another story.] to achive an essentially zero
source resistance
preamp design in a very noisy physically stringent external environment
ultmately
driving a 24 bit A/D converter behind which the customer's application
attempts
to accurately extract important measurements from the remote source.
For a sensitivity analysis of this filter circuit we need to know the
maximum attenuation
deviations *in the passband* [delta Ap dB's] and in the group delay due to
temperature
humidity, pressure and other variations.
The passband attenuation deviations for lossless element fractional
variations [eps]
and element resistance variations are calculated by the well known formuas:
1 - Max delta Ap (dB) < 8.68*|eps||*2*pi*fm*taum/[1 - |rho|^2]
2 - Max delta Ap (dB) = 4.34*[1/Q + d]*2*pi*fm*taum
Where Q is the average coil Q and d is the average capacitor dissipation,
which along
with eps all vary with temperature in this application, and taum is the
maximum value of
group delay and fm is the frequency of maximum group delay and rho is the
reflection
coefficient. [Hint: both of the delay peaks and both of their frequencies
occur in the
passband not in a notch!]
The customer's back end application needs to know the exact value of the
group
delay at the band edges 1kHz and 1.4kHz as well as the total variation of
delay throughout
the passband so that post processing after the 24 bit DSP can equalize the
delay. [I'm
using a Cirrus/CrystalADC on this project].
My point in bringing up these admitedly somewhat arcane sensitivity formuae,
is that
to evaluate this design quickly one needs to know.
1.) The "exact" value of the group delay at the passband edges of 1kHz and
1.4 kHz?
2.) The *exact* values of maximum group delay and their exact frequencies?
3.) The total variation of delay taumax - taumin between1kHz and 1.4kHz?
LT SPICE does not make these problem of delay analysis easy! In fact the LT
Spice
group delay outputs are downright misleading!
LT is decidedly user unfriendly and misleading on this score! And what is
worse, it offers
no advice to the unwary user!
LT Spice merrily pumps out potentially erroneous delay answers and calls
them "group delay".
These LT Spice group delay results may or may not have any relationship to
reality, and what's
more don't even correspond to data available from commercial delay test
sets.
On the other hand there are other programs out there for which obtaining
these kinds
of group delay results are a piece of cake and so I don't depend upon SPICE
for these
kinds of results.
And... apparently from the feedback I am getting from this group including
SPICE authors
and others, no one cares! So be it. Don't listen to customers.
Getting goup delay output from LT Spice? I say... "Caveat Emptor"!
--
Peter
Consultant
Indialantic By-the-Sea, FL.
Peter Brackett
[snip]
"> Move the mouse to the right of the right axis. The mouse cursor
> turns into a vertical ruler trying to indicate that you're pointing
> at that axis' attributes. Left mouse click. Then check the group
> delay radio button under representation. All three axes attributes
> are edited in a similar mouse syntax.
>
> --Mike
[snip]
Great job on those axis attribute editors, I love them.
Peter Brackett
[snip]
> > What was it John Cleese once said on a Faulty Tower's episode, "Never
> > kill a customer!"
> >
>
> Theres a new hotel/restaurant in, Manchester I believe, styled on Faulty
> Towers, customer insults and all. Apparently everyone thinks its great.
>
>
> Kevin Aylward
[snip]
Heh, heh... I love Monty Python, Faulty Towers and John Cleese. Cleese
dabbled in the management consulting business a few years ago. Some of his
sketches were/are classic examples of how not to treat a customer!
Cheers,
Peter Brackett
[snip]
> > Let me make it simple.
> >
> > If changing the number and density of the frequency analysis points
> > in your network analysis program changes the values of your so-called
> > group delay output at any frequency point then... IT IS NOT GROUP
> > DELAY!
>
> In the limit df->0 the results will be the same. That is, keep reducing
> the frequency step size until the last value of GD is the same as the
> next one with some prescribed accuracy.
>
> >
> > True group delay can be evaluated at a single frequency point!
> >
>
> That correct. However, one looks at the *limit* as (G(f+df) - G(f))/df
> as df->0
[snip]
Heh, heh...
Kevin my friend, your back hand comments in response to my
suggestion/complaint remind me of the Norwegian Blue skit from Monty Python.
That parrot's not dead! He's just resting!
:-)
Peter Brackett
[snip]
> > Try this with a 40 Hz "split" and compare with a point analysis and see
> how
> > awkward/difficult it becomes to do the comparison analysis near the
peaks.
> >
>
> Hello Peter,
> indeed it has very steep notches and thus we will need a high resolution
in
> the frequency domain. It is all ok, if we reduce the frequency steps below
> 0.2Hz in our simulation.
>
> .AC LIN 20001 400 2400 * (0.1Hz resolution)
>
> The results are very consistent for any number of steps above 10000,
> and I am shure they are equal to your calculations.
>
> Summary:
> (LT)SPICE has calculated it correctly. It is just the user who can cause
> wrong calculations if he doesn't set enough frequency resolution.
> May be someone can give an easy estimation of the maximum frequency
> step allowed in .AC analysis for group delay, depending on the steepest
> dPhi/dFreq.
>
> Best Regards
> Helmut
[snip]
Not you also!
You all seem to have your heads stuck in the notches.
Notches are black holes, no one [except Physiscist and Mathematicians] care
what
happens in black holes [notches].
It's not the notches where the problem lies!
The problem lies in finding the group delay peaks, the frequency of their
peaks and
the total group delay variation and then the correlation of those calculated
values
with actual laboratory measurements.
Helmut see another post of mine a little further up the thread where I
elaborate
a little more on what folks really need from a group delay analysis.
To parphrase Bill Clintons old campaign slogan, "It's the delay peaks,
stupid!"
:-)
Best,
Peter Brackett
[snip]
> > Submit a single frequency point to your Spice program and see what
> > happens?
>
> You obviously don't know the basics of calculus. Differentiation is a
> limiting process. See my other post.
>
> Kevin Aylward
[snip]
"That parrot's not dead!"
--
Peter Brackett
[snip]
> > Submit a single frequency point to your Spice program and see what
> > happens?
>
> You obviously don't know the basics of calculus. Differentiation is a
> limiting process. See my other post.
>
> Kevin Aylward
[snip]
Hmphh.. Mathematicians and limits. Y'all know nothing about electrical
engineering and the physics of the electrical networks your programs are
analyzing! ;-)
Kevin, *you* obviously don't know the basics of network analysis.
For a textbook tutorial on only one way to calculate the exact analytic
group delay of electrical networks from formulas with no numerical
difference quotionts/differentiation of trig functons, using element values
and and each single frequency point without using derivatives or limiting
processes, see for instance...
DeVerl S. Humpherys, "The Analysis Design and Synthesis of Electrical
Filters", Prentice-Hall, Englewood Cliffs, NJ 1970. See pages: p. 139 -
141 and the complete Fortran listing of the program CGNLAD on page 623.
I personally know of two other ways to do this and I personally have written
and use in my own consulting practice several programs [Fortran 95] which,
unlike those kludgey SPICE programs provide elegant, simple, unambigous
exact anlytic group delay outputs.
Why can't ya'll do the same?
Stop complaining...
Just do it!
Peter Brackett
[snip]
> Hello Peter,
> I just have read a chapter about group delay measurement from
> "Wandel and Goltermann". They indeed have(had?) analyzers which use
> this modulation method with 40Hz you also mentioned.
[snip]
What? You didn't believe me? ;-(
[snip]
> But finally this is nothing more than measuremet the phase difference
> 40Hz apart. Tg=delta_phase/40Hz
[snip]
Precisely one of my points!
[snip]
> The most probably mistake you can make here is sweeping too fast.
>
> If you want do that 40Hz spacing in SPICE, eg. from 50Hz to 20kHz,
> then simply run a ".AC lin 501 30 20030".
> It calculates the phase with 40Hz step size at 30Hz, 70Hz, 110Hz, ...
> and from that the group delay with Tg=delta_phase/40Hz for the mean
> frequencies 50Hz, 90Hz and so on.
>
> Logaritmic scales could be done with precalculated frequencies
> .AC LIST (freq1-20Hz), (freq1+20Hz), (freq2-20Hz), (freq2+20Hz) ....
> Ok, here is eventually some post processing necessary if you donn't
> like the inbetween calculated group delay points.
[snip]
Why should I go to all of that trouble when I have better network analysis
programs which don't require me to go to all that effort and which return
the "correct" analytic point group delay for each and every frequency
point.
[snip]
> I am still waiting for a circuit from you where SPICE has failed.
> Please provide a circit that we really can discuss about SPICE flaws
> regarding group delay.
[snip]
Done!
[snip]
> To Mike,
> please don't change the word group delay in LTSPICE to any other
> like "split frequency delay". This would lead to a lot of confusion.
>
> Best Regards
> Helmut
[snip]
As a knowledgeable and experienced group delay jockey and customer I
disagree!
The use of the words "group delay" in the LT Spice vertical axis dialog box
and on the axis labels
without caveats is both misleading and potentially error prone!
Call it what it is, "split frequency group delay"!
Then follow it up in the program documentation with an on-screen note and a
paragraph in the
Help File under "group delay" with a caveat stating "The delay values are
computed by a numerical
differentiation [difference quotient] derived from phase values computed
trigonometrically at adjacent
frequency points and so are subject to errors. The user is advised to
carefully chose the start and
end frequencies and number of frequency analyis points and/or specify an
exact frequency list to
ensure accurate delay results".
Kevin Aylward
> Kevin:
>
> [snip]
>>> Submit a single frequency point to your Spice program and see what
>>> happens?
>>
>> You obviously don't know the basics of calculus. Differentiation is a
>> limiting process. See my other post.
>>
>> Kevin Aylward
> [snip]
>
> Hmphh.. Mathematicians and limits. Y'all know nothing about
> electrical engineering and the physics of the electrical networks
> your programs are analyzing! ;-)
>
> Kevin, *you* obviously don't know the basics of network analysis.
Ahmmm...
>
> For a textbook tutorial on only one way to calculate the exact
> analytic group delay of electrical networks from formulas with no
> numerical difference quotionts/differentiation of trig functons,
> using element values and and each single frequency point without
> using derivatives or limiting processes, see for instance...
>
Your talking nonsense. GD is *defined* by the rate of change of phase,
i.e. its derivatives. You can't do this without taking limits. End of
story.
Maybe you have another definition of GD, like your other left arm.
> DeVerl S. Humpherys, "The Analysis Design and Synthesis of Electrical
> Filters", Prentice-Hall, Englewood Cliffs, NJ 1970. See pages: p.
> 139 - 141 and the complete Fortran listing of the program CGNLAD on
> page 623.
>
I'm not intrested in code.
Present your alternative mathematical definition of GD, that don't use
derivatives.
> I personally know of two other ways to do this and I personally have
> written and use in my own consulting practice several programs
> [Fortran 95] which, unlike those kludgey SPICE programs provide
> elegant, simple, unambigous exact anlytic group delay outputs.
>
Show us your new definition then.
Kevin Aylward
Nonsense. What you are doing is not GD. It is *your* definition that is
in error. As I said, its bit like the audio boys, who claim THD, by only
adding up some arbitrary number of harmonics, instead of them all.
Mike Engelhardt
> Heh, heh... interesting notches. What is it about notches?
>
> y'all are still working on the WRONG problem.
>
> Forget about the notches! Notches are "black holes"!
>
> Read my posts! No one cares about the delay in a notch!
It's hardest to compute group delay at/near notches. One
needs to take many frequency points to approach the derivative
with finite differences. Also, there can be a singularity
to handle and different programs handle this differently.
Anywhere else is trivial to compute group delay with SPICE.
A discussion of computing group delay with SPICE gravitates
to the notches because that's where the difficult action is.
> The areas of importance in group delay analysis are
> at or near delay peaks which are generally no where
> near notches.
There we showed you how to get group delay with LTspice.
It's trivial to get the correct answer to 1ppm. This was
an arbitrary accuracy number. You can compute it even
more accurately. You can use the attached cursor to query
the data anywhere near the delay peaks.
> ...an ultra low noise Op Amp [Currently an LT-1128,
> en = 3nV/rtHz, enk=2.3Hz, in=1.3pA/rtHz ink=100Hz
> whose LT Spice model I currently have a problem
> with, but Mike... that's another story.]
Noise is usually not modeled in the opamp macro models.
I recommend that you use the universal opamp macro models
1pole and 2pole that allow noise to be specified with
en, in, enk, and ink.
> The passband attenuation deviations for lossless element
> fractional variations [eps] and element resistance
> variations are calculated by the well known formuas:
Perhaps your problem isn't the way that group delay is
computed but that inductors aren't lossless by default
in LTspice. You can go to the control panel to change
them to be lossless.
--Mike
Peter Brackett
[snip]
> Perhaps your problem isn't the way that group delay is
> computed but that inductors aren't lossless by default
> in LTspice. You can go to the control panel to change
> them to be lossless.
>
> --Mike
[snip]
Oh! I didn't know that.
Thanks for the "heads up" that one could easily have got me sometime.
Peter Brackett
[snip]
> Show us your new definition then.
>
> Kevin Aylward
[snip]
What? Hey... I didn't say I had a new definition of group delay!
You are not reading my posts closely enough.
What I beleive I stated was that one can compute group delay without using
numerical differentiation of the phase function based on transcendental
functions [trigonometric functions].
Instead one can compute group dealy exactly directly from analytic formulae
in the form of rational polynomial functions.
For a transfer function H(p) group delay tau(w) is defined and evaluated at
angular radian frequencies w = 2*pi*f, along the imaginary axis of the
complex frequency p-plane (p=s+jw), by writing
H(w)=Re{H(w)}+jIm{H(w)}=R(w)+jX(w) and calculating from the simple
derivative formulas we all learned in Calculus 101:
tau(w) = d[phi(w)]/dw = d[arctan[X(w)/R(w)] = {[X(w)d[R(w)/dw] -
R(w)d[X(w)/dw]{/{R(w)^2 + X(w)^2}
Which one can readily see, since God has blessed us with the fact that the
derivative of the arctan often "kills" the propagation of transendentals
i.e. d[arctan(u(x)]dx = d[u(x)/dx]*[1/(1+u(x)^2)] :-) ] that if H(p) was/is
a rational polynomial, then with analytic continuation [i.e. w->p/j] then
tau(w) is also a rational polynomial and "trancendental free" and...
Voila... we find that tau(p) is actually a simple rational function of p and
does not require the use of trigonometry for evaluation!
In fact we will find that tau(p) can be evaluated directly by means of a
simple formula from the impedances and admittances and the derivatives of
those impedances and admittances themselves.
As your odal analyis computer algorithm evaluating its' [programmed in]
formulas for impedances and admittances also evaluated built in formulas for
their derivatives, a slightly augmented nodal matrix, it is a simple matter
at the end to form/calculate the group delay tau [and the network
sensitivities] for output directly from the formulas.
No need to call expensive to evaluate trigonometric functions, no need for
numerical differentiation!
Get exact group analytic group delay from simple rational polynomials
formulas in p without evaluating arctangents.
It's much faster, more accurate and it is exact without performing error
prone numerical differentiation.
And as a side benefit it can pump out network sensitivities.
Wow! Neat!
But... subtle eh?
Details to be worked out by the Mathematician!
But of course if you want the actual "split frequency delay" you will have
to revert to the present method of operation, only don't forget that what
you do now actually computes an approximation to the split frequency delay
at frequencies halfway between the user specified frequencies and don't
allow him to specify the split for log frequency scales!
Cheers,
--
Peter
Consultant
Indialantic By-the-Sea, FL.
Peter Brackett
[snip]
> Nonsense. What you are doing is not GD. It is *your* definition that is
> in error. As I said, its bit like the audio boys, who claim THD, by only
> adding up some arbitrary number of harmonics, instead of them all.
>
> Kevin Aylward
[snip]
*My* definition of group delay is:
tau(w) = d[phi(w)]/dw.
Check it out in any textbook or technical dictionary.
What you compute today is [I believe,please correct me if I'm wrong.]:
tau split(w1) = [phi(w2) - phi(w2)][/[w2 - w1]
Where w1 and w2 are only known to the program user indirectly!
I rest my case!
What?
--
Peter
Consultant
Indialantic By-the-Sea, FL.
analog
Mike Engelhardt, Peter Brackett wrote:
>> Heh, heh... interesting notches. What is it about notches?
>>
>> y'all are still working on the WRONG problem.
Yes, they are. They all have been mislead by your quibbling about
about practically meaningless terminological differences.
>> Forget about the notches! Notches are "black holes"!
>>
>> Read my posts! No one cares about the delay in a notch!
I understand. Although designing to true group delay within the
filter's pass band is the most direct way to meet your customer's
needs, you still would like a method to directly simulate and verify
the split group delay of the design, since that is all that can be
measured in the real world.
> It's hardest to compute group delay at/near notches. One needs to
> take many frequency points to approach the derivative with finite
> differences. Also, there can be a singularity to handle and
> different programs handle this differently. Anywhere else is trivial
> to compute group delay with SPICE. A discussion of computing group
> delay with SPICE gravitates to the notches because that's where the
> difficult action is.
LTspice does an outstanding job of computing true group delay with
fine detail. (But it needs a little coaxing to be able to do the
same with split group delay - see my other post for a "how to".)
>> The areas of importance in group delay analysis are at or near
>> delay peaks which are generally no where near notches.
>
> There we showed you how to get group delay with LTspice. It's
> trivial to get the correct answer to 1ppm. This was an arbitrary
> accuracy number. You can compute it even more accurately. You can
> use the attached cursor to query the data anywhere near the delay
> peaks.
All true and well done, but not really what Peter is interested in.
To my understanding, he wants and appreciates being able to simulate
true group delay with such accuracy and fineness of detail, but also
would like to simultaneously simulate and display true split delay
with the same accuracy and fineness of detail.
And although it calculates and stores all the data it would need to
do this, LTspice presently can't directly access response data from
any but the single current frequency being processed for display at
the moment it is being displayed.
What Peter wants for an .ac analysis a way to be able to reach
backwards and forwards in frequency within the data set. By allowing
the use of "time" and "freq" in waveform arithmetic expressions,
LTspice appears to come tantalizing close.
...
analog
Kevin Aylward
And in the limit, to as good as accuracy as one pleases, letting dw->0,
gives you the GD.
I rest my case.
Kevin Aylward
> Kevin:
>
> [snip]
>> Show us your new definition then.
>>
>> Kevin Aylward
> [snip]
>
> What? Hey... I didn't say I had a new definition of group delay!
>
> You are not reading my posts closely enough.
>
> What I beleive I stated was that one can compute group delay without
> using numerical differentiation of the phase function based on
> transcendental functions [trigonometric functions].
>
So what. And this is new?
> Instead one can compute group dealy exactly directly from analytic
> formulae in the form of rational polynomial functions.
>
{Snip, elementary, pretensious calculus}
We aren't all ignorant of basic maths you know,
http://www.anasoft.co.uk/physics/gr/index.html
>
> Voila... we find that tau(p) is actually a simple rational function
> of p and does not require the use of trigonometry for evaluation!
>
> In fact we will find that tau(p) can be evaluated directly by means
> of a simple formula from the impedances and admittances and the
> derivatives of those impedances and admittances themselves.
>
> As your odal analyis computer algorithm evaluating its' [programmed
> in] formulas for impedances and admittances also evaluated built in
> formulas for their derivatives, a slightly augmented nodal matrix, it
> is a simple matter at the end to form/calculate the group delay tau
> [and the network sensitivities] for output directly from the formulas.
>
> No need to call expensive to evaluate trigonometric functions, no
> need for numerical differentiation!
Jesus wept dude. Look, I got the stock Spice3/XSpice code. It took me
about 20 minuets to add post processing GD. Why on earth would I want to
go to the bother of pissing about with the code, when my GD is as
*accurate* as one *pleases* by making dw->0.
>
> Get exact group analytic group delay from simple rational polynomials
> formulas in p without evaluating arctangents.
>
> It's much faster, more accurate and it is exact without performing
> error prone numerical differentiation.
>
There isn't any error in the numerical differentiation that matters.
> And as a side benefit it can pump out network sensitivities.
>
> Wow! Neat!
>
> But... subtle eh?
>
> Details to be worked out by the Mathematician!
>
> But of course if you want the actual "split frequency delay" you will
> have to revert to the present method of operation, only don't forget
> that what you do now actually computes an approximation to the split
> frequency delay at frequencies halfway between the user specified
> frequencies and don't allow him to specify the split for log
> frequency scales!
>
What I do now is an approximation to d(ph(w))/dw, which is as accurate
as one wishes it to be.
Jim Thompson
<ke...@anasoft.co.uk> wrote:
>Peter Brackett wrote:
[snip]
>> tau split(w1) = [phi(w2) - phi(w1)][/[w2 - w1] [typo corrected]
>>
>> Where w1 and w2 are only known to the program user indirectly!
>>
>> I rest my case!
>
>And in the limit, to as good as accuracy as one pleases, letting dw->0,
>gives you the GD.
>
>I rest my case.
>
>Kevin Aylward
Methinks Peter began his weekend drinking on Thursday ;-)
Peter Brackett
[snip]
> What Peter wants for an .ac analysis a way to be able to reach
> backwards and forwards in frequency within the data set. By allowing
> the use of "time" and "freq" in waveform arithmetic expressions,
> LTspice appears to come tantalizing close.
> ...
> analog
[snip]
Thanks!
I couldn't have said it better myself.
The best "scenario" for group delay designers would have been to leave the
traditional
SPICE .AC outputs alone and not add a dodgy so-called "group delay" output
tacked onto
the output file.
Hey, the "Original SPICE" card deck .AC directive never produced a group
delay output,
they were happy to just print out the "true phase angle". There were no
"misleading" labels
on post-computed "funny" delay numbers!
What the "new" SPICEs [LT Spice, SuperSpice, PSpice... etc.] authors
*should* have done
to create delay outputs that are really helpful to actual group delay
designers was perhaps to have
added a new SPICE directive for ac analysis.
Let's call this new directive the ".DEL"directive.
The .DEL card would causes simultaneous outputs of both "tgr(w) = the group
delay" i.e.
the closest possible approximation the program can make to the actual "true"
derivative at
any frequency point w *and* a true split delay "tsp(w, split) = split group
delay" where
the user can specify the "split" at exactly the same frequency points w.
The "Real Group Delay"
tgr(w) = d[phi(w)]/dw "The true group delay"
*And* a "True Split Delay" output that allows the user to specify a "split"
to match his delay measuring set.
tsp(w) = [phi(w2) - phi(w1)]/[w2 - w1] ; where w = (w1 + w2)/2 "The
laboratory test set "split delay".
A columnar output tabulation of delay from this ideal SPICE .DEL dual delay
output would look like:
Frequency (Hz), True Group Delay (sec), Split Group Delay [xx Hz split]
(sec)
1.000 Hz, 1.345 sec, 0.456 sec
1.010 Hz, 1.276 sec, 0.450 sec
:
:
etc...
Of course overlaid graphical outputs of both would be very nice!
As with the .AC directive card, the new .DEL card should allow the user to
specify arbitrary start frequency, end frequency, logarithmic or linear
steps,
number of points, etc... including the use of any arbitrary number of
frequency
points including just one or two [previously known to the user] frequency
points.
Of course since SPICE's internal nodal analysis does not carry along
derivatives
both of these outputs [tgr(w) and tph(w) would have to be calculated from
finite
differences wthin the SPICE program by calculating the appropriate number
and
placement of the frequency points submitted by the program's internal logic
to the
internal analyzer loop. i.e.for each w specified by the user, the program
would have
to likely calculate phi at four other nearby frequency points to get the
"right" answers.
i.e. When the user has specified a frequency point w, internally SPICE would
calculate and use nearby points w1, w2, w3, and w4. Say with
w1 = (w - split/2), w2 = (w + split/2) using the user supplied "split" and
w3,
w4 suitably chosen by some new SPICE program internal algorithm transparent
to the user to produce a reasonably accurate approximation to the analytic
point
group delay:
tgr(w) = d[phi(w)]/dw = lim [phi(w4) - phi(w3)]/[w4 - w3] as [w4 - w3] -> 0
As Mike, Kevin and others have illustrated while "bashing" me for suggesting
that their programs may have imperfections :-) [and with Moore's law
helping]
simply specifying a large number of points for analysis allows the new
SPICE's
to come as closely as necessary to the actual analytic derivative based
group delay.
As long as the user is knowledgeable enough about group delay, *and* knows
that the SPICE uses finite differences to calcualte delay and not the actual
group
delay!
I say, great!
Llet LT Spice, SuperSpice, PSpice run as many points as they *need*
to get accurate delay results...
Just don't ask the user to accept responsibility for deciding how many
points
he needs to get accurate delay results with no way of knowing how to do it!
It's a terrible situation that the current SPICE's don't even advice the
user that his
delay results are calculated by a finite difference and that even those
results are not
valid at the points specified but are offset in frequency!
I will not accept the cheap attempts to intimidate me on this Newsgroup, all
of
the current SPICE group delay outputs are WRONG, INCORRECT, and
definitely NOT USER FRIENDLY!
Nuff said!
Without prejudice,
--
Peter
Consultant [Who just want's honesty in SPICE outputs!]
Indialantic By-the-Sea, FL
Peter Brackett
[snip]
> Methinks Peter began his weekend drinking on Thursday ;-)
>
> ...Jim Thompson
[snip]
Hey... I drink *every* day! hic... hic ;-)
Kinda touchy and defensive these SPICE jockeys, eh!
Both of em, I mean... Kevin [The Mathematician] and Mike [The Physicist]!
Stay cool out there in AZ. We got a nice SouthEast Trade wind coming in off
the ocean here today.
Best,
--
Peter
Consultant [Looking for honesty in SPICE outputs!]
Indialantic By-the-Sea, FL.
Jim Thompson
<ab...@ix.netcom.com> wrote:
>Hi Jim:
>
>[snip]
>> Methinks Peter began his weekend drinking on Thursday ;-)
>>
>> ...Jim Thompson
>[snip]
>
>Hey... I drink *every* day! hic... hic ;-)
>
>Kinda touchy and defensive these SPICE jockeys, eh!
>
>Both of em, I mean... Kevin [The Mathematician] and Mike [The Physicist]!
>
>Stay cool out there in AZ. We got a nice SouthEast Trade wind coming in off
>the ocean here today.
>
>Best,
>Peter
We're having a cool one ourselves.
At 1:45PM it's 97°F, pool at 83°F
Strange place Arizona, humidity so low that the pool loses 4°F
overnight. I can watch the solar controller kick in at 9:00AM (when
the pump starts)... within an hour the pool is back to 83°F.
Peter Brackett
[snip]
> Strange place Arizona, humidity so low that the pool loses 4°F
> overnight. I can watch the solar controller kick in at 9:00AM (when
> the pump starts)... within an hour the pool is back to 83°F.
>
> ...Jim Thompson
[snip]
Yes, I remember AZ well, having worked for Motorola way back when, I spent
more than a few
weeks out there in Phoenix. I was there on a project one time at the old
MICARL for the whole
month of August, got used to it after a week or so. I miss the steaks at
Pinnacle Peak. Is that
restaurant still up there?
Say, how much water do you lose from your pool? Do you hafta replace it
with "city water" often?
The problem I have with my pool out here in our Florida place in the summer
is that in the wet
season [summer] it will quickly overflow whenever we get about 4-5 inches of
rain in an hour
or so from one of those summer cloudbursts. I have to keep a close eye on
it and pump
it out into the sewer! If I don't watch it closely it overflows and kills
the lawn in the back yard.
My wife spends summers at our condo up in Eastern Canada, I have to stay
here to "mind" the
pool and watch for hurricanes.
But then again... I do like the surfing, surf sailing and fishing.
Best,
Kevin Aylward
> Analog:
>
> [snip]
>> What Peter wants for an .ac analysis a way to be able to reach
>> backwards and forwards in frequency within the data set. By allowing
>> the use of "time" and "freq" in waveform arithmetic expressions,
>> LTspice appears to come tantalizing close.
>> ...
>> analog
> [snip]
>
>
> SPICE would calculate and use nearby points w1, w2, w3, and w4. Say
> with w1 = (w - split/2), w2 = (w + split/2) using the user supplied
> "split" and w3,
> w4 suitably chosen by some new SPICE program internal algorithm
> transparent to the user to produce a reasonably accurate
> approximation to the analytic point
> group delay:
>
> tgr(w) = d[phi(w)]/dw = lim [phi(w4) - phi(w3)]/[w4 - w3] as [w4 -
> w3] -> 0
>
> As Mike, Kevin and others have illustrated while "bashing" me for
> suggesting that their programs may have imperfections :-)
Not at all its not bashing. We are being completely objective on
*technical* issues. The fact that you don't agree with the evaluation
does not amount to bashing.
>[and with
> Moore's law helping]
> simply specifying a large number of points for analysis allows the new
> SPICE's
> to come as closely as necessary to the actual analytic derivative
> based group delay.
> As long as the user is knowledgeable enough about group delay, *and*
> knows that the SPICE uses finite differences to calcualte delay and
> not the actual group
> delay!
>
What your suggesting is equivalent to a mechanic not knowing that
spanners come in more than one size.
You need to know at least the basics of your tools. Even driving a tek
scope or HP analyser needs a certain amount of knowledge and skill to
get correct results out of it. For example, a user, needs to be aware
there is a default relative tolerance in spice that may need to be set,
depending on what he is examining.
> I say, great!
>
> Llet LT Spice, SuperSpice, PSpice run as many points as they *need*
> to get accurate delay results...
>
> Just don't ask the user to accept responsibility for deciding how many
> points
> he needs to get accurate delay results with no way of knowing how to
> do it!
>
Lets get real here. The idea that one should be *totally* ignorant of
ones tools is completely daft. Sure, no one is expecting a user to have
detailed knowledge of numerical methods, however, if a user of, e.g. GD,
does not know the basics of calculus, he isn't going to be able to make
much use of Spice anyway. Spice is an analogue design/analysis tool,
designed for electronic engineers. There is no escaping this. Sure,
there are companies that try and push, the "any idiot can drive our tool
and produce expert results", but this is marketing waffle.
> It's a terrible situation that the current SPICE's don't even advice
> the user that his
> delay results are calculated by a finite difference and that even
If anyone has even the *slightest* understanding of derivatives, i.e,
qualified to be actually looking at GD in Spice, they will have a fair
guess that something like that is going on. Spice is a technical tool.
It is not for plumbers.
Frazier Episode:
(car broken down)
"If you look in the glove compartment, you will see a flash light and a
small toolkit... behind them is my mobile phone, will you pass it to me
so I can call a mechanic."
> those results are not
> valid at the points specified but are offset in frequency!
>
As I keep on saying, this is not true. In the limit df->0, its as
accurate as one pleases.
> I will not accept the cheap attempts to intimidate me on this
> Newsgroup, all of
> the current SPICE group delay outputs are WRONG, INCORRECT,
Absolute rubbish. It has been pointed out to you many times what the
definition of GD is, and why Spice satisfies that definition.
and
> definitely NOT USER FRIENDLY!
>
Since they don't give what a pro GD designer what he wants, you may have
an argument on this point.
Peter Brackett
[snip]
> > those results are not
> > valid at the points specified but are offset in frequency!
>
> As I keep on saying, this is not true. In the limit df->0, its as
> accurate as one pleases.
[snip]
I know, I know... given eps > 0 there exists h such that..."
That's a nice statement for a Mathematician to make... and yes
it is true as anyone who has taken Calculus 101 knows that, but...
Do you SPICE authors really have to make the SuperSpice/LT Spice
user actually take the limits manually as you do now?
Taking the limits manually by resubmitting the .AC analysis card
with ever increasing density of frequency analysis points until getting
stable group delay convergence will be very awkward for most users,
especially for crystal and mechanical filter applications!
And... why make the user "take the limit manually" by analyzing
over and over again himself *only* for group delay? Ya'll don't
ask users to take limits for any other output function.
It seems that, at least LT Spice goes to great lengths to jump through
hoops to make the group delay correct for the user deep in those
notches, where the user doesn't care, but... where it counts most,
in the delay peaks, ya'll do nothing to help the user with group
delay computations.
As a simple [but demanding] test case for group delay analysis at
a peak of group delay, try computing the group delay of a
simple one crystal crystal filter. Place the crystal in a single series
arm between a 50 Ohm source and a 50 Ohm load and let er rip!
If you need some typical crystal parameters, I suggest you try a
common garden variety TV color burst crystal.
--
Peter
Consultant
Indialantic By-the-Sea, FL.
:
:
>
> Since they don't give what a pro GD designer what he wants, you may have
> an argument on this point.
>
>
> Kevin Aylward
[snip]
Peter Brackett
[snip]
> Since they don't give what a pro GD designer what he wants, you may have
> an argument on this point.
>
>
> Kevin Aylward
[snip]
Ahhhh... grudging acceptance of a simple suggestion.
Now... hold that thought.
Hurry and implement my suggestions for proper split delay and group delay
operation of SuperSpice quickly in the next release and beat Englehardt to
the
punch!
No charge for the advice!
Keep up the good customer relations work.
;-)
Dr. Gerhart Hlawatsch
this mixed domain simulations. But perhaps somebody here knows?
Good luck!
Gerhart
> > Q: re group delay calculations.
> >
> [...]
>
> >
> > Actually I'm curious about all versions of SPICE's in general, and how
> > they calculate group delay output?
>
> Well, not a Spice-like program, but the filter analysis/optimisation program
> LCP2 by H Gaunholt[1] of the Technical University of Denmark uses proper
> derivative calculations.
>
> LCP2 is a goold old program (with emphasis on both), without a user-friendly
> drag-and-drool interface[2] but with a really superb number-crunching
> engine.
...
>
> Regards
>
> Jens
>
> [1] http://www.oersted.dtu.dk/personal/hg/
Charles DH Williams
<ab...@ix.netcom.com> wrote:
>
> Do you SPICE authors really have to make the SuperSpice/LT Spice
> user actually take the limits manually as you do now?
>
> Taking the limits manually by resubmitting the .AC analysis card
> with ever increasing density of frequency analysis points until getting
> stable group delay convergence will be very awkward for most users,
> especially for crystal and mechanical filter applications!
This strikes me as a case where the traditional 'nutmeg' (interctive
frontend) for Spice scores over the GUI's
I can get reasonable group delays by running an AC analysis, and then
plotting the deriv() of the result. (A few simple bugs in the Berkeley
code need to be fixed for this to work). Deriv() uses local polynominal
interpolation.
To get the spit group delay one needs to be a bit tricky. Create two
shifted frequency scales, f1=frequency+$shift/2 and f2=frequency-$shift/2,
interpolate the AC plot onto these, subtract the results and divide by
$shift.
Charles
Helmut Sennewald
news:C.D.H.Williams-...@cw-mac.ex.ac.uk...
> In article <bd958f$d17$1...@slb6.atl.mindspring.net>, "Peter Brackett"
> <ab...@ix.netcom.com> wrote:
> >
> > Do you SPICE authors really have to make the SuperSpice/LT Spice
> > user actually take the limits manually as you do now?
> >
> > Taking the limits manually by resubmitting the .AC analysis card
> > with ever increasing density of frequency analysis points until getting
> > stable group delay convergence will be very awkward for most users,
> > especially for crystal and mechanical filter applications!
>
> This strikes me as a case where the traditional 'nutmeg' (interctive
> frontend) for Spice scores over the GUI's
>
> I can get reasonable group delays by running an AC analysis, and then
> plotting the deriv() of the result.
Hello Charles,
the only difference to LTSPICE is that "your" deriv() does a polynomal
fit of the data from the .AC simulation whereas LTSPICE does only
calculate the phase difference divided by the frequency distance.
So both methods rely on the limited number of data points from
the .AC simulation. Computers are so fast today, that we can choose
so much frequency points that the difference between both methods
should become very small.
> (A few simple bugs in the Berkeley
> code need to be fixed for this to work). Deriv() uses local polynominal
> interpolation.
I am interested how this polynomal interpolation works exactly.
Could you tell more details?
Best Regards
Helmut
Charles DH Williams
the vector created by interpolate(plot.vector) is the result of
interpolating the named vector onto the scale of the current plot. This
function uses the variable polydegree to determine the degree of
interpolation.
It works its way along plot.vector fitting a $polydegree polynominal at
each step and evaluates this at points on the current scale.
> Could you tell more details?
My hack at plotting the group delay and the split group delay using only
Berkeley 3f4 spice commands is below. Half the code is needed to unwrap
the phase because there is no unwrap() function in 3f5. No need to do this
if you don't mind a handful of glitches, or if your implementation has an
unwrap() function. With a linear sweep, a few hundred points in the ac
analysis seem to be enough, as one would guess. This method should also
work fine with a log sweep.
Were the 'correct' answers ever posted for this problem? If so, I missed them.
Charles
For group delay analysis
Rnix N006 0 1G
RS N002 N001 1
L1 N003 N002 0.626m
C2 N004 N003 29.49u
L3 N004 N005 63.79u
C3 N005 0 1.2687m
C4 N004 0 361.8u
C5 N006 N004 35.75u
L5 N004 N006 231.3u
C8 0 Out 31.41u
L7 0 Out 54.71u
RL Out 0 1.888
VS N001 0 AC 1.0 0.0
C6 Out N006 37.99u
.control
set shift = 40
set units = radians
ac lin 500 400 2400
plot db(v(out))
let ph = ph(v(out))
* unwrap the phase
let j = 1
let n = 0
let piradians = 4*atan(1.0)
dowhile j < length(v(out))
label tryagain
if (ph[j] + n * windup - ph[j-1] ) > piradians*0.5
let n = n - 1
goto tryagain
else
if (ph[j-1] - ph[j] - n * windup) > piradians*0.5
let n = n + 1
goto tryagain
end
end
let ph[j] = ph[j] + n *piradians
let j = j + 1
if (j % 256) = 0
echo -n "."
end
end
echo " "
plot ph
let f = real(frequency)
setscale f
setplot new
let f1 = real(ac.frequency - $shift/2)
setscale f1
let splitgroup1 = interpolate(ac.ph)
let f1 = f1 + $shift
let splitgroup2 = interpolate(ac.ph)
let f1 = real(ac.frequency)
echo "Using shift = $shift Hz"
plot (splitgroup2-splitgroup1)/$shift deriv(ac.ph)
.endc
.end
Helmut Sennewald
news:C.D.H.Williams-...@cw-mac.ex.ac.uk...
> <HelmutS...@t-online.de> wrote:
> >
> > I am interested how this polynomal interpolation works exactly.
>
> the vector created by interpolate(plot.vector) is the result of
> interpolating the named vector onto the scale of the current plot. This
> function uses the variable polydegree to determine the degree of
> interpolation.
>
Hello Charles,
thanks for your answer. What value have you set for "polydegree"?
I have read in a manual that its default is 1(linear), isn't it?
> It works its way along plot.vector fitting a $polydegree polynominal at
> each step and evaluates this at points on the current scale.
>
> > Could you tell more details?
>
> My hack at plotting the group delay and the split group delay using only
> Berkeley 3f4 spice commands is below. Half the code is needed to unwrap
> the phase because there is no unwrap() function in 3f5. No need to do this
> if you don't mind a handful of glitches, or if your implementation has an
> unwrap() function. With a linear sweep, a few hundred points in the ac
> analysis seem to be enough, as one would guess. This method should also
> work fine with a log sweep.
>
> Were the 'correct' answers ever posted for this problem? If so, I missed
them.
I haven't seen it too.
Peter,
could you post a table with measured split delay data?
Best Regards
Helmut
My results from LTSPICE after post processing with Ltsputil.exe + Excel
LTSPICE: .ac lin 2001 400 2400 f_split=40Hz
Freq Split-GD GD
...
990.000 3.71E-03 3.61E-03
991.000 3.81E-03 3.73E-03
992.000 3.91E-03 3.85E-03
993.000 4.01E-03 3.97E-03
994.000 4.11E-03 4.10E-03
995.000 4.20E-03 4.23E-03
996.000 4.30E-03 4.36E-03
997.000 4.39E-03 4.49E-03
998.000 4.49E-03 4.62E-03
999.000 4.57E-03 4.75E-03
1000.000 4.66E-03 4.88E-03
1001.000 4.74E-03 5.01E-03
1002.000 4.82E-03 5.14E-03
1003.000 4.89E-03 5.26E-03
1004.000 4.96E-03 5.38E-03
1005.000 5.02E-03 5.50E-03
1006.000 5.08E-03 5.60E-03
1007.000 5.13E-03 5.70E-03
1008.000 5.18E-03 5.79E-03
1009.000 5.22E-03 5.87E-03
1010.000 5.26E-03 5.93E-03
1011.000 5.29E-03 5.99E-03
1012.000 5.31E-03 6.03E-03
1013.000 5.33E-03 6.06E-03
1014.000 5.34E-03 6.07E-03
1015.000 5.35E-03 6.07E-03
1016.000 5.35E-03 6.06E-03
1017.000 5.34E-03 6.03E-03
1018.000 5.33E-03 5.99E-03
1019.000 5.31E-03 5.94E-03
1020.000 5.29E-03 5.87E-03
1021.000 5.25E-03 5.80E-03
1022.000 5.22E-03 5.71E-03
1023.000 5.18E-03 5.62E-03
1024.000 5.13E-03 5.52E-03
1025.000 5.08E-03 5.41E-03
1026.000 5.02E-03 5.30E-03
1027.000 4.96E-03 5.18E-03
1028.000 4.89E-03 5.06E-03
1029.000 4.82E-03 4.94E-03
1030.000 4.74E-03 4.81E-03
1031.000 4.67E-03 4.69E-03
1032.000 4.58E-03 4.57E-03
1033.000 4.50E-03 4.44E-03
1034.000 4.41E-03 4.32E-03
1035.000 4.33E-03 4.20E-03
1036.000 4.24E-03 4.09E-03
1037.000 4.15E-03 3.97E-03
1038.000 4.06E-03 3.86E-03
1039.000 3.97E-03 3.76E-03
1040.000 3.88E-03 3.65E-03
...
The LTSPICE circuit from "analog":
Version 4
SHEET 1 1868 1332
WIRE 80 128 48 128
WIRE 48 128 48 544
WIRE 160 128 192 128
WIRE 272 128 304 128
WIRE 400 128 400 176
WIRE 528 128 528 224
WIRE 576 176 608 176
WIRE 576 176 576 128
WIRE 576 80 608 80
WIRE 672 176 720 176
WIRE 720 176 720 128
WIRE 720 80 688 80
WIRE 528 288 528 400
WIRE 400 352 400 400
WIRE 400 256 400 288
WIRE 368 128 400 128
WIRE 400 128 528 128
WIRE 576 128 576 80
WIRE 720 128 752 128
WIRE 720 128 720 80
WIRE 816 128 848 128
WIRE 848 128 960 128
WIRE 848 224 848 128
WIRE 1072 128 1072 224
WIRE 960 224 960 128
WIRE 848 288 848 400
WIRE 1072 400 1072 304
WIRE 960 304 960 400
WIRE 848 400 528 400
WIRE 1072 416 1072 400
WIRE 528 128 576 128
WIRE 528 400 400 400
WIRE 960 128 1024 128
WIRE 960 400 848 400
WIRE 960 400 1072 400
WIRE 1024 128 1072 128
WIRE 80 544 48 544
WIRE 160 544 192 544
WIRE 272 544 304 544
WIRE 400 544 400 592
WIRE 528 544 528 640
WIRE 576 592 608 592
WIRE 576 592 576 544
WIRE 576 496 608 496
WIRE 672 592 720 592
WIRE 720 592 720 544
WIRE 720 496 688 496
WIRE 528 704 528 816
WIRE 400 768 400 816
WIRE 400 672 400 704
WIRE 368 544 400 544
WIRE 400 544 528 544
WIRE 576 544 576 496
WIRE 720 544 752 544
WIRE 720 544 720 496
WIRE 816 544 848 544
WIRE 848 544 960 544
WIRE 848 640 848 544
WIRE 1072 544 1072 640
WIRE 960 640 960 544
WIRE 848 704 848 816
WIRE 1072 816 1072 720
WIRE 960 720 960 816
WIRE 848 816 528 816
WIRE 528 544 576 544
WIRE 528 816 400 816
WIRE 960 544 1024 544
WIRE 960 816 848 816
WIRE 960 816 1072 816
WIRE 1024 544 1072 544
WIRE 1072 832 1072 816
WIRE 80 960 48 960
WIRE 160 960 192 960
WIRE 272 960 304 960
WIRE 400 960 400 1008
WIRE 528 960 528 1056
WIRE 576 1008 608 1008
WIRE 576 1008 576 960
WIRE 576 912 608 912
WIRE 672 1008 720 1008
WIRE 720 1008 720 960
WIRE 720 912 688 912
WIRE 528 1120 528 1232
WIRE 400 1184 400 1232
WIRE 400 1088 400 1120
WIRE 368 960 400 960
WIRE 400 960 528 960
WIRE 576 960 576 912
WIRE 720 960 752 960
WIRE 720 960 720 912
WIRE 816 960 848 960
WIRE 848 960 960 960
WIRE 848 1056 848 960
WIRE 1072 960 1072 1056
WIRE 960 1056 960 960
WIRE 848 1120 848 1232
WIRE 1072 1232 1072 1136
WIRE 960 1136 960 1232
WIRE 848 1232 528 1232
WIRE 528 960 576 960
WIRE 528 1232 400 1232
WIRE 960 960 1024 960
WIRE 960 1232 848 1232
WIRE 960 1232 1072 1232
WIRE 1024 960 1072 960
WIRE 1072 1248 1072 1232
WIRE 48 960 48 544
WIRE 48 960 48 1056
WIRE 48 1136 48 1232
WIRE 48 1232 400 1232
FLAG 1024 128 Out
FLAG 1072 416 0
FLAG 1024 544 Out1
FLAG 1072 832 0
FLAG 1024 960 Out2
FLAG 1072 1248 0
SYMBOL voltage 48 1040 R0
WINDOW 123 25 96 Left 0
WINDOW 39 -32 56 VBottom 0
SYMATTR Value2 AC 1 100
SYMATTR InstName VS
SYMATTR Value ""
SYMBOL res 64 144 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName RS
SYMATTR Value 1
SYMBOL ind 176 144 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 5 56 VBottom 0
SYMATTR InstName L1
SYMATTR Value 0.626m
SYMATTR SpiceLine Rser=0
SYMBOL cap 304 144 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C1
SYMATTR Value 29.49µ
SYMBOL ind 384 160 R0
SYMATTR InstName L2
SYMATTR Value 63.79µ
SYMATTR SpiceLine Rser=0
SYMBOL cap 384 288 R0
SYMATTR InstName C2
SYMATTR Value 1.2687m
SYMBOL cap 512 224 R0
SYMATTR InstName C3
SYMATTR Value 361.8µ
SYMBOL cap 608 192 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C4
SYMATTR Value 35.75µ
SYMBOL ind 592 96 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 5 56 VBottom 0
SYMATTR InstName L3
SYMATTR Value 231.3µ
SYMATTR SpiceLine Rser=0
SYMBOL cap 752 144 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C5
SYMATTR Value 37.99µ
SYMBOL cap 832 224 R0
SYMATTR InstName C6
SYMATTR Value 31.41µ
SYMBOL ind 944 208 R0
SYMATTR InstName L4
SYMATTR Value 54.71µ
SYMATTR SpiceLine Rser=0
SYMBOL res 1056 208 R0
SYMATTR InstName RL
SYMATTR Value 1.888
SYMBOL res 64 560 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName RS1
SYMATTR Value 1
SYMBOL ind 176 560 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 5 56 VBottom 0
SYMATTR InstName L5
SYMATTR Value 0.626m
SYMATTR Prefix X
SYMATTR SpiceModel Lsplit L=
SYMBOL cap 304 560 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C7
SYMATTR Value 29.49µ
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMBOL ind 384 576 R0
SYMATTR InstName L6
SYMATTR Value 63.79µ
SYMATTR Prefix X
SYMATTR SpiceModel Lsplit L=
SYMBOL cap 384 704 R0
SYMATTR InstName C8
SYMATTR Value 1.2687m
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMBOL cap 512 640 R0
SYMATTR InstName C9
SYMATTR Value 361.8µ
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMBOL cap 608 608 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C10
SYMATTR Value 35.75µ
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMBOL ind 592 512 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 5 56 VBottom 0
SYMATTR InstName L7
SYMATTR Value 231.3µ
SYMATTR Prefix X
SYMATTR SpiceModel Lsplit L=
SYMBOL cap 752 560 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C11
SYMATTR Value 37.99µ
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMBOL cap 832 640 R0
SYMATTR InstName C12
SYMATTR Value 31.41µ
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMBOL ind 944 624 R0
SYMATTR InstName L8
SYMATTR Value 54.71µ
SYMATTR Prefix X
SYMATTR SpiceModel Lsplit L=
SYMBOL res 1056 624 R0
SYMATTR InstName RL1
SYMATTR Value 1.888
SYMBOL res 64 976 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName RS2
SYMATTR Value 1
SYMBOL ind 176 976 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 5 56 VBottom 0
SYMATTR InstName L9
SYMATTR Value 0.626m
SYMATTR Prefix X
SYMATTR SpiceModel Lsplit L=
SYMATTR Value2 sf={-sf}
SYMBOL cap 304 976 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C13
SYMATTR Value 29.49µ
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMATTR Value2 sf={-sf}
SYMBOL ind 384 992 R0
SYMATTR InstName L10
SYMATTR Value 63.79µ
SYMATTR Prefix X
SYMATTR SpiceModel Lsplit L=
SYMATTR Value2 sf={-sf}
SYMBOL cap 384 1120 R0
SYMATTR InstName C14
SYMATTR Value 1.2687m
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMATTR Value2 sf={-sf}
SYMBOL cap 512 1056 R0
SYMATTR InstName C15
SYMATTR Value 361.8µ
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMATTR Value2 sf={-sf}
SYMBOL cap 608 1024 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C16
SYMATTR Value 35.75µ
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMATTR Value2 sf={-sf}
SYMBOL ind 592 928 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 5 56 VBottom 0
SYMATTR InstName L11
SYMATTR Value 231.3µ
SYMATTR Prefix X
SYMATTR SpiceModel Lsplit L=
SYMATTR Value2 sf={-sf}
SYMBOL cap 752 976 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C17
SYMATTR Value 37.99µ
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMATTR Value2 sf={-sf}
SYMBOL cap 832 1056 R0
SYMATTR InstName C18
SYMATTR Value 31.41µ
SYMATTR Prefix X
SYMATTR SpiceModel Csplit C=
SYMATTR Value2 sf={-sf}
SYMBOL ind 944 1040 R0
SYMATTR InstName L12
SYMATTR Value 54.71µ
SYMATTR Prefix X
SYMATTR SpiceModel Lsplit L=
SYMATTR Value2 sf={-sf}
SYMBOL res 1056 1040 R0
SYMATTR InstName RL2
SYMATTR Value 1.888
TEXT 48 -160 Left 0 !.ac lin 2001 400 2400
TEXT 576 -280 Center 0 ;Cauer Band Pass Split Delay Demo\nby ana...@ieee.org
TEXT 496 -168 Left 0 !.subckt Csplit 1 2\nB1 1 2 I=V(1,2)*C
laplace=s*(1+{pi*sf}/abs(s))\n.ends Csplit
TEXT 48 -56 Left 0 ;Split Delay (cut & paste) =
TEXT 496 -72 Left 0 !.subckt Lsplit 1 2\nB1 1 2 V=I(B1)*L
laplace=s*(1+{pi*sf}/abs(s))\n.ends Lsplit
TEXT 48 -128 Left 0 !.param sf=40
TEXT 232 640 Center 0 ;Upper (f+sf/2)\nSplit Frequency\nCircuit
TEXT 232 1056 Center 0 ;Lower (f-sf/2)\nSplit Frequency\nCircuit
TEXT 48 -24 Left 0 ;(ph(V(out1))-ph(V(out2)))/(360*40)
TEXT 232 224 Center 0 ;Center (f)\nFrequency\nCircuit
Dietmar Warning
news:C.D.H.Williams-...@cw-mac.ex.ac.uk:
> In article <bdpuuo$b17$02$1...@news.t-online.com>, "Helmut Sennewald"
> <HelmutS...@t-online.de> wrote:
>>
>> I am interested how this polynomal interpolation works exactly.
>
> the vector created by interpolate(plot.vector) is the result of
> interpolating the named vector onto the scale of the current plot.
> This function uses the variable polydegree to determine the degree of
> interpolation.
>
> It works its way along plot.vector fitting a $polydegree polynominal
> at each step and evaluates this at points on the current scale.
>
>> Could you tell more details?
>
> My hack at plotting the group delay and the split group delay using
> only Berkeley 3f4 spice commands is below. Half the code is needed to
> unwrap the phase because there is no unwrap() function in 3f5. No need
> to do this if you don't mind a handful of glitches, or if your
> implementation has an unwrap() function. With a linear sweep, a few
> hundred points in the ac analysis seem to be enough, as one would
> guess. This method should also work fine with a log sweep.
>
> Were the 'correct' answers ever posted for this problem? If so, I
> missed them.
>
> Charles
>
Hello Charles,
can you tell us something about the source code changes you have
introduced. At the moment the code of interpolate and deriv is switched of
in my ng-spice code. What is the main problem with this?
Thanks
Dietmar
Charles DH Williams
<HelmutS...@t-online.de> wrote:
> thanks for your answer. What value have you set for "polydegree"?
> I have read in a manual that its default is 1(linear), isn't it?
default for polydegree is 1, and for dpolydegree is 2.
Okay, using a slightly fixed version of my script (posted below) using 200
points in the analysis routine and interpolating using polydegree = 3 ,
and dpolydegree 4 I get the following results which are pretty much inline
with yours. Obviously, I've got a sign missing somewhere and I could
smartent things up by interpolating on to a scale with a nicer spacing,
but life's too short...
Charles.
Index (f1) (splitgroup2-sp deriv(ac.ph)/(8
--------------------------------------------------------------------------------
55 9.527638e+02 -1.31381e-03 -1.24426e-03
56 9.628141e+02 -1.69030e-03 -1.58121e-03
57 9.728643e+02 -2.24347e-03 -2.07954e-03
58 9.829146e+02 -3.03060e-03 -2.83102e-03
59 9.929648e+02 -4.00505e-03 -3.92365e-03
60 1.003015e+03 -4.89112e-03 -5.21113e-03
61 1.013065e+03 -5.33365e-03 -6.00047e-03
62 1.023116e+03 -5.17166e-03 -5.64382e-03
63 1.033166e+03 -4.48632e-03 -4.50650e-03
64 1.043216e+03 -3.58974e-03 -3.39773e-03
65 1.053266e+03 -2.82235e-03 -2.63432e-03
66 1.063317e+03 -2.30313e-03 -2.16871e-03
67 1.073367e+03 -1.99575e-03 -1.90420e-03
68 1.083417e+03 -1.83927e-03 -1.77434e-03
69 1.093467e+03 -1.78944e-03 -1.74008e-03
70 1.103518e+03 -1.81888e-03 -1.77910e-03
For group delay analysis
Rnix N006 0 1G
RS N002 N001 1
L1 N003 N002 0.626m
C2 N004 N003 29.49u
L3 N004 N005 63.79u
C3 N005 0 1.2687m
C4 N004 0 361.8u
C5 N006 N004 35.75u
L5 N004 N006 231.3u
C8 0 Out 31.41u
L7 0 Out 54.71u
RL Out 0 1.888
VS N001 0 AC 1.0 0.0
C6 Out N006 37.99u
.control
set shift = 40
set polydegree = 3
set dpolydegree = 4
set units = radians
ac lin 200 400 2400
plot db(v(out))
let ph = ph(v(out))
* unwrap the phase
let j = 1
let n = 0
let piradians = 4*atan(1.0)
dowhile j < length(v(out))
label tryagain
if (ph[j] + n*piradians - ph[j-1] ) > (piradians*0.5)
let n = n - 1
goto tryagain
else
if (ph[j-1] - ph[j] - n*piradians ) > (piradians*0.5)
let n = n + 1
goto tryagain
end
end
let ph[j] = ph[j] + n*piradians
let j = j + 1
if (j % 256) = 0
echo -n "."
end
end
echo " "
plot ph
let f = real(frequency)
setscale f
setplot new
let f1 = real(ac.frequency - $shift/2)
setscale f1
let splitgroup1 = interpolate(ac.ph)
let f1 = f1 + $shift
let splitgroup2 = interpolate(ac.ph)
let f1 = real(ac.frequency)
echo "Using shift = $shift Hz"
plot (splitgroup2-splitgroup1)/(8*atan(1.0)*{$shift}) deriv(ac.ph)/(8*atan(1.0))
print (f1) (splitgroup2-splitgroup1)/(8*atan(1.0)*{$shift})
deriv(ac.ph)/(8*atan(1.0))
.endc
.end
Charles DH Williams
Warning <war...@danalyse.de> wrote:
> can you tell us something about the source code changes you have
> introduced. At the moment the code of interpolate and deriv is switched of
> in my ng-spice code. What is the main problem with this?
AFAIR Interpolate is okay, and there were a couple of typo/bugs in the
complex section of "deriv()" which are fairly obvious if you compare the
broken complex code with the working real code.
Charles.
Mike Engelhardt
> > user actually take the limits manually as you do now?
> >
> > Taking the limits manually by resubmitting the .AC analysis card
> > with ever increasing density of frequency analysis points until getting
> > stable group delay convergence will be very awkward for most users,
> > especially for crystal and mechanical filter applications!
>
> This strikes me as a case where the traditional 'nutmeg' (interctive
> frontend) for Spice scores over the GUI's
>
> I can get reasonable group delays by running an AC analysis, and then
> code need to be fixed for this to work). Deriv() uses local polynominal
> interpolation.
This will usually give more accurate group delay with a given number
of points, but it's also potentially harder to interpret the error.
But there's not much excuse for curvefitting data when it's so easy
to compute in the first place. It's really is better to just have
more frequency data points. LTspice, unlike Berkeley SPICE, can have
elements with arbitrary frequency response specified in look-up tables.
It's a bit presumptuous to assume you can interpolate.
> Were the 'correct' answers ever posted for this problem? If so,
> I missed them.
The original poster finally posted the circuit he had trouble with.
We showed him how to compute group delay to 1 part per million
accuracy in LTspice. Then he decided it wasn't OK to use that
method to compute group delay because of some reason only he
understood.
I believe it was all a non-issue. For the nature of data from a .ac
analysis, the robustness of simple finite difference works well and
is extremely accurate. How LTspice computes group delay is apparent.
You can turn on "Mark Data Points" and see the group delay points
halfway between the frequency points. Also, it's probably not safe
to say that plotting group delay is a case where nutmeg scores over
LTspice since LTspice handles data more efficiently than nutmeg it
can handle more real data instead of curve-fitted messes. LTspice
also knows about the singularities that can occur in group delay and
handles them in a reasonable manner -- very helpful when autoranging
is turned on.
BTW, LTspice's finite difference method basically the same method
used in other design software(even non-SPICE based for arbitrary
network analysis software that I've used when designing group
delay equalized systems. I found it incredulous that the original
poster was having difficulty with it. For split frequency group
delay, the easiest thing to do is contrive a .ac analysis with coarse
frequency steps, though Analog's circuit is worth studying for it's
cleverness and demonstration of articulating a SPICE simulation
with mixed methods on a schematic.
--Mike
Peter Brackett
[snip]
> The original poster finally posted the circuit he had trouble with.
> We showed him how to compute group delay to 1 part per million
> accuracy in LTspice. Then he decided it wasn't OK to use that
> method to compute group delay because of some reason only he
> understood.
[snip]
WRONG!
Mike I don't use SPICE to compute group delay, never have, probably
never will.
My interest in group delay is on the approximation, synthesis analysis and
design
of analog and digital group delay requirements. I have my own [decades old]
programs
which I have developed for the approximation synthesis, design and analysis
of analog
and ditgital [dsp] group delay problems.
In this regard, since SPICE can *only* do analysis of analog circuits
it would be of limited usefullness to me.
However... and this was the point of my original posts, the group delay
analysis
capability of SPICE might be of use to less sophisticated users such as my
clients
[but not to me]. Prior to my original posts to this NG, I had already
suspected that you might have been using a post computation graphical "hack"
for group
delay results and I had already instructed a client as to how to "take the
limit" as delta_f
goes to zero... to get around this defficiency!
[snip]
> I believe it was all a non-issue. For the nature of data from a .ac
> analysis, the robustness of simple finite difference works well and
> is extremely accurate. How LTspice computes group delay is apparent.
> You can turn on "Mark Data Points" and see the group delay points
> halfway between the frequency points. Also, it's probably not safe
> to say that plotting group delay is a case where nutmeg scores over
> LTspice since LTspice handles data more efficiently than nutmeg it
> can handle more real data instead of curve-fitted messes. LTspice
> also knows about the singularities that can occur in group delay and
> handles them in a reasonable manner -- very helpful when autoranging
> is turned on.
>
> BTW, LTspice's finite difference method basically the same method
> used in other design software(even non-SPICE based for arbitrary
> network analysis software that I've used when designing group
> delay equalized systems. I found it incredulous that the original
> poster was having difficulty with it. For split frequency group
> delay, the easiest thing to do is contrive a .ac analysis with coarse
> frequency steps, though Analog's circuit is worth studying for it's
> cleverness and demonstration of articulating a SPICE simulation
> with mixed methods on a schematic.
>
> --Mike
[snip]
Mike, the original poster[me] did not have trouble with it! Heh, heh...
I agree with your assesment, it is all a "non-issue".
You just refuse to accept customer feedback and *fix* LT Spice and
that's it!
A non issue! :-)
Mike Engelhardt
> > Mike wrote:
> > The original poster finally posted the circuit he had trouble with.
> > We showed him how to compute group delay to 1 part per million
> > accuracy in LTspice. Then he decided it wasn't OK to use that
> > method to compute group delay because of some reason only he
> > understood.
>
> WRONG!
>
> Mike I don't use SPICE to compute group delay, never have, probably
> never will.
>
> In this regard, since SPICE can *only* do analysis of analog circuits
> it would be of limited usefullness to me.
Yes, SPICE is an analysis tool. You enter a circuit and it computes
the group delay. It can't synthesis a circuit for a which you specify
a group delay. We all know that's the way SPICE programs work.
But your complaint was that LTspice didn't compute group delay.
When we demonstrated that it did, you didn't like the method
it used and seemed to have trouble with calculus despite both
detailed help from Kevin and demonstration that it could compute
group delay to <1ppm. Then you want to pigeon hole the people helping
you into categories like physicist or mathematician. That's a form of
bigotry. Everyone today is an interdisciplinarian. And yes, in particular,
I have designed group-delay equalized systems and circuits. Ever notice
that LTspice is the only SPICE with a built-in eye diagram plotting mode.
(That's what is used to assess the impact of group delay distortion in
digital communication systems.)
> > I believe it was all a non-issue. For the nature of data from a .ac
> > analysis, the robustness of simple finite difference works well and
> > is extremely accurate. How LTspice computes group delay is apparent.
> > You can turn on "Mark Data Points" and see the group delay points
> > halfway between the frequency points. Also, it's probably not safe
> > to say that plotting group delay is a case where nutmeg scores over
> > LTspice since LTspice handles data more efficiently than nutmeg it
> > can handle more real data instead of curve-fitted messes. LTspice
> > also knows about the singularities that can occur in group delay and
> > handles them in a reasonable manner -- very helpful when autoranging
> > is turned on.
> >
> > BTW, LTspice's finite difference method basically the same method
> > used in other design software(even non-SPICE based for arbitrary
> > network analysis software that I've used when designing group
> > delay equalized systems. I found it incredulous that the original
> > poster was having difficulty with it. For split frequency group
> > delay, the easiest thing to do is contrive a .ac analysis with coarse
> > frequency steps, though Analog's circuit is worth studying for it's
> > cleverness and demonstration of articulating a SPICE simulation
> > with mixed methods on a schematic.
>
> --Mike
>
> Mike, the original poster[me] did not have trouble with it! Heh, heh...
>
> I agree with your assesment, it is all a "non-issue".
>
> You just refuse to accept customer feedback and *fix* LT Spice and
> that's it!
>
> A non issue! :-)
But here the problem is clearly in your head. I could only fix the
problem if it were in LTspice. Claiming that you're right because
(you claim) you're the customer is pretty lame out here in Usenet.
Frankly, on a more important and man-to-man level, you might want to
address that asinine resentment you chose to harbor over all this.
Some people claim benefit in seeing a therapist, others try a group
at church, if you're into that sort of thing. There's the soc.*
newsgroups. Of course, the natural desire is to just want to nurse
the resentment along. What it is.
--Mike
Peter Brackett
[snip]
> Frankly, on a more important and man-to-man level, you might want to
> address that asinine resentment you chose to harbor over all this.
> Some people claim benefit in seeing a therapist, others try a group
> at church, if you're into that sort of thing. There's the soc.*
> newsgroups. Of course, the natural desire is to just want to nurse
> the resentment along. What it is.
>
> --Mike
[snip]
Hey, we can all see from you postings that *you* are quite a man Mike.
I especially admire your reactions to criticism... excellent grist for any
theraputic group.
Mike you must not take critiques of your *baby* personally.
LT Spice is an excellent piece of work, congratulations on that
accomplishment.
And while I am at it, also kudos to your employer Linear Technology Corp.
for supporting you and allowing such an excellent tool to be made available
free of charge! I for one feel grateful for that. I have been a patron of
many of Linear Technologies great products and have specified LT parts into
my designs of well in excess of $15MM worth of Linear's parts in production
designs over the years. Keep up the good work.
Let's hear it for Linear Technology, yeah!
OTOH... I still feel that your misuse of the term group delay for the
outputs purported to be group delay presented by LT Spice are at best a
misnomer and at worst completely error prone.
:-)
But don't let my opinion of LT Spice's cheap "hack" for group delay affect
your feelings of self worth.
Best Regards,
Mike Engelhardt
> I especially admire your reactions to criticism...
> excellent grist for any theraputic group.
My policy there is to thank everyone with a bug report.
I try to let people know I value each and every one
of them no matter how they choose to communicate it
to me, e.g., phone call, direct e-mail(see the help
about box), the users' group, or Usenet. But I can't
fix the problem if it isn't in the program.
> OTOH... I still feel that your misuse of the term
> group delay for the outputs purported to be group
> delay presented by LT Spice are at best a
> misnomer and at worst completely error prone.
Yes, well, we've exhausted that possibility and
found no basis for this view. LTspice computes
the group delay of your circuit. Just because you
don't like the method, well, doesn't matter. I'm
certainly sticking by my method because it is
correct even for arbitrary circuits. It doesn't
take much familiarity in the field to see it's
widely used and accepted, even outside of SPICE
programs.
> But don't let my opinion of LT Spice's cheap "hack" for
> group delay affect your feelings of self worth.
Yes, this reminds me that Moses is credited for writing
that he was the humblest man on walking the earth at
that time.
Otherwise, thanks for all the kind words.
--Mike
Peter Brackett
[snip]
> Otherwise, thanks for all the kind words.
>
> --Mike
[snip]
You are most welcome, I appreciate your efforts.