Zoltan's Simulation

[gyula]

Dear poynt99,

In your last picture I can see AVG (W(V1)) for the input supply power and not RMS like for the output resistor.
I wonder if the software could consider the RMS power taken from the supply, or it is the same in this case? Sorry, I am not fully familiar with this pspice terminology.

Thanks, Gyula

[MileHigh]

.99: Thanks, the PDF makes all the difference.

You are looking an an "esoteric" RMS power calculation. It is the "current running RMS power through the load starting at time zero." (say that 10 times). For every incremental step forward in time, the software is doing a whole new RMS calculation for the incrememtally larger time span. At least that's what it looks like to me. Effectively you are recalculating the RMS power every time you take a time step. That's not what you want.

Going back to your waveform graph, you should find the function in your software package where you can place the "start" cursor at 1.55 msec, and the "end" cursor at 1.6 msec. Then you click on the "RMS Calc" button (or whatever it's called) and in a few seconds it will spit out your chosen RMS value for one full period of your waveform. Good luck!

MileHigh

[poynt99]

Dear poynt99,

In your last picture I can see AVG (W(V1)) for the input supply power and not RMS like for the output resistor.
I wonder if the software could consider the RMS power taken from the supply, or it is the same in this case? Sorry, I am not fully familiar with this pspice terminology.

Thanks, Gyula

Gyula,

Yes, this is the confusing thing about using SPICE, and I am sure it has caught many people. I myself am unsure sometimes what I am doing and have to check and re-check my thinking to keep things straight.

RMS power in a device is calculated (by SPICE) by calculating the instantaneous power (instantaneous V times instantaneous I), then performing a running average of this for the time shown on the display. That is why the calculation has a lot of "ripple" at the beginning of the curve and why it smooths out over time.

Now for RMS, I believe it does not matter the polarity of the product, i.e. + or -, there is probably an "absolute value" inherent in the process. RMS is concerned with equivalent DC level so it converts all to one polarity. It does not matter if a resistor is heating because of positive or negative current, it is heating and dissipating some power and that is all that matters. This is exactly what is done for calorimetry tests is it not?

For the V1 showing AVE, yes I choose that rather than RMS because the value does not come out correct otherwise. I have done a manual calculation for the V1 source taking into account the switch duty cycle (i.e. current from the source) and it works out the same as SPICE using the AVE function.

I'd be happy to try some simple tests with wave forms and RMS measurements if anyone wants to, to verify the validity of what I'm saying here. I'm not perfect, and could very well be making an error here myself.

.99

[poynt99]

SPICE seems to treat DC voltage and current sources differently, and the reason is I think because the V and I are already "DC". As such doing a forced RMS calculation on it causes an incorrect result, even though it should not.

Again, I am not 100% sure about what goes no "under the hood" of SPICE, and it has been a challenge for me for some time since I began working on my SPICE Joule meter model.

Perhaps I'll put together some wave forms, theoretical calculations and PSpice outputs. This would be a good exercise to straighten this out once and for all. It will also let me know if so far I've made any errors or not...hope not

.99

[MileHigh]

From the CrackerJax box:

>
PROBE Math Capabilities

PROBE has the capability for the use of mathematical functions for data processing and display of the data as a function of an independent variable. The following list presents the functions available for use in generating new and different data representations in PROBE.

RMS(x) running RMS average of x over the range of the X axis variable.
>

The language above doesn't make me comfortable. However, if the "range of the x axis variable" means you can set a start time and a stop time and it spits out a single RMS calculation number that should be correct.

Other cool PROBE functions I noticed:

PWR(x,y) xy
SQRT(x) x½

These two are very important:

d(x) derivative of x with respect to the X axis variable.
s(x) integral of x over the range of the X axis variable.

It's way cool! lol

[poynt99]

MH,

Why does the running average trouble you?

It does indeed come to the correct value when checked against a manual calculation. I have tried it with a worst case wave form I came up with.

A pulse train of 0.05% duty cycle with alternating positive (+2V) and negative (-4V) pulses. Using the formula I posted in the document for gotoluc, PSpice calculates the RMS running average to be right on my manual RMS calculation. And to emphasize again, you do not use a range from "here to there" really, although you do specify a time range (but you do anyway for all transient analysis types), you are only interested in the final value (infinite time) that the averaging comes to. It WILL settle to a final value and IT DOES NOT MATTER AFTER THIS POINT WHERE YOU TAKE THE MEASUREMENT. The value has plateaued to the equivalent DC value.

This is of course with a PERIODIC wave form that DOES NOT CHANGE IN RMS AMPLITUDE WITH TIME, and this is precisely what we have here with these pulse measurements.

Hope that makes sense to you now

.99

[MileHigh]

.99: I think that I have got it. What if I word it like this: You can set a time range, and in principle it does not matter the start and stop time because it is a periodic waveform. Now I am going to split hairs: You really want the time range to at least be an integer multiple of your periodic waveform's period. That way you can "slide" your time window across your waveform and the RMS calc will always be the same. The "running RMS" calculation is indeed a repeatedly updating value, hence the curves on the graph. Therefore it is really the LAST value in the "running RMS" calculation that is the "true" RMS value for the whole time period.

It can be argued that the "running RMS" calculation is information overkill, you don't need it for your application. It's just that today's home PC processors are so unbelievably fast that they have the luxury of computing the running RMS calculation so they do it for you.

Thanks for the feedback. At risk of being a pain, if you went about 200+ cycles down in your waveform, to a point where you assume that the long time constant has stabilized (although it never really does! lol) enough, and then try to do the calc on one full waveform and see what the final numbers are in the running RMS calculation it would be amazing. The reason I say this is that I suspect that you may have jumped the gun in your RMS power graph. You can clearly see how the lower waveform has a much longer time constant and you may still be climbing for quite a while. You may not be getting the right data.

MileHigh

[poynt99]

.99: I think that I have got it. What if I word it like this: You can set a time range, and in principle it does not matter the start and stop time because it is a periodic waveform. Now I am going to split hairs: You really want the time range to at least be an integer multiple of your periodic waveform's period. That way you can "slide" your time window across your waveform and the RMS calc will always be the same. The "running RMS" calculation is indeed a repeatedly updating value, hence the curves on the graph. Therefore it is really the LAST value in the "running RMS" calculation that is the "true" RMS value for the whole time period.

Yes, precisely!

It can be argued that the "running RMS" calculation is information overkill, you don't need it for your application. It's just that today's home PC processors are so unbelievably fast that they have the luxury of computing the running RMS calculation so they do it for you.

It is not overkill at all. SPICE performs resolves the RMS value EXACTLY the way an integrated IC version would in real time. It is also analogous to obtaining an FFT. The more samples you can give, the better your resolution and accuracy.

SPICE HAS to do it this way (i.e running average) because it does not "know" what your period is, or even IF there is a period. It does not care. It is just converting whatever you throw at it to an equivalent DC value. That is why these chips are called RMS-DC converters.

Thanks for the feedback. At risk of being a pain, if you went about 200+ cycles down in your waveform, to a point where you assume that the long time constant has stabilized (although it never really does! lol) enough, and then try to do the calc on one full waveform and see what the final numbers are in the running RMS calculation it would be amazing.

This will not work. Again, not enough cycles. It will look like oscillation as you see in the pic already provided (right at the start).

The reason I say this is that I suspect that you may have jumped the gun in your RMS power graph. You can clearly see how the lower waveform has a much longer time constant and you may still be climbing for quite a while. You may not be getting the right data.

MileHigh

I doubt that very much. How long of a run would you like to see to convince you that the values I have obtained from a 2ms run will be substantially the same?

.99

[poynt99]

Here is the run again but at 20ms. This is 10x the original time.

.99

PS. I see the trick is to upload jpg's, not gif's. The image will be ok if you try it now.

[gyula]

Gyula,

...
For the V1 showing AVE, yes I choose that rather than RMS because the value does not come out correct otherwise. I have done a manual calculation for the V1 source taking into account the switch duty cycle (i.e. current from the source) and it works out the same as SPICE using the AVE function.

I'd be happy to try some simple tests with wave forms and RMS measurements if anyone wants to, to verify the validity of what I'm saying here. I'm not perfect, and could very well be making an error here myself.

.99

Thanks for your kind answer, I understand.
I would have a motion, if you agree, how about making a low-pass filter in the software and place it between the 1.5V battery and the coil L1? The break frequency would be well under the 20kHz switching frequency, with at least a 60dB attenuation @20kHz. This way a DC current meter could be inserted in series with the battery positive, before the wire enter into the filter. Maybe the true input power could be obtained that way? (W=V*I)

(I think a high value capacitor ought to be placed in parallel with the common point of L1 and of the low-pass filter and the negative gnd to imitate the short circuit behavior of the battery which would now be isolated from the circuit by the filter.)

If you think this low pass filter test is not necessary, it is ok.

rgds, Gyula

[poynt99]

Yes gyula,

This is ok.

Aethertech also suggested something similar and I think I will try it next. He suggested a PI-type filter using two large caps with a 10 Ohm (or so) shunt in between. Supply on input side, and circuit on the output side. We monitor current via the shunt and multiply by output cap voltage.

Will this satisfy your suggestion as well?

.99

[MileHigh]

.99: That was awesome posting the jpec and it addressed the time constant issue.

However, I picked up on the fact that you were discussing the AVE (Averaging?) function for "Watts associated with V1"?? I am not clear there. I think that you should poke around some more.

Can you "drop in another probe" at node 1 of L1? You want to probe the current at that point and get the running RMS current there and compare that to your probe showing you the running RMS power through R1. Is that making any sense?

I assume that knowing the running RMS curent through L1 and with the voltage fixed at 1.5 volts, you can also plot the RMS power from the power supply entering in at node 1 of L1.

------> RMS(I(L1)) ---- something like that?
------> RMS(W(I(L1)x1.5volts)) ---- something like that?

MileHigh

Edit: .99: The more I look at it the more it looks like measuring the average power is simply a built-in function that you were using. If that's the case that makes sense and I am more or less stumped. The ripples don't make sense to me unless I am missing something. The only think I think it could be is that each ripple is related to a sampling point, and then the software is running some kind of low-pass filter on the discrete points just for display purposes and it is causing the ripples. That would imply lowering the delta-T because it is too gramular for your waveform's time period. Decreasing the delta-T by a factor of ten might make that go away, still leaving the problem of the COP > 1. lol

[gyula]

.99 Yes, it sounds ok, though I would prefer a coil or two coils in a double Pi filter instead of the 10 Ohm resistor... lol I do not usually fancy using a member of a filter for current monitoring at the same time...

Well do as you like of course, the point is to find a different way for getting to the real input power.

Thanks, Gyula

EDIT: here is a simple calculator for getting some ballpark element values:
http://www.wa4dsy.net/filter/hp_lp_filter.html and for a 3 pole filter with 1kHz break frequency:
http://www.wa4dsy.net/cgi-bin/lc_fil...funits=HZ&Z=50
(I think on the lower circuit in the bottom)

[poynt99]

MH,

Check your PM I sent earlier today.

.99

[RAMSET]

These are the kind of posts I dream about

poynt99
Zoltan's Done it!

Zoltan's a genius!

Power dissipated in R1 (the load): 7.904mW RMS

Power supplied from V1 Source: 5.678mW RMS

COP = 1.39



.99

Even if this changes

I know I will see this [or better] In one of your posts soon

THANK YOU SOOO MUCH FOR TAKING THE TIME!!!

Chet