¿ªÔÆÌåÓý

Date

Re: LTSpive IV vs XVII voltage generators

 

Larry wrote about changed behavior between LTspice IV and LTspice XVII, when a sine wave voltage or current source has Ncycles.

? ? "I assume this was done intentionally or is this possibly an error."

Looking at LTspice's Help, I think it was an old bug that has finally been found and fixed.? The way it behaves now, is the way it was always SUPPOSED to be.

The LTspice IV Help page says that the output before Td or after Ncycles have completed, should be:

? ? V(time) = Voffset?+ Vamp * sin(PI*Phi/180)
? ? I(time) = Ioffset?+ Iamp * sin(PI*Phi/180)

Therefore its steady starting AND ending values should have been the value at that point along the sine wave where it starts and ends, determined by Phi.? Thus the sine wave should be continuous at both ends.? (But even that description is in error, because Ncycles doesn't need to be an integer, and because it doesn't take Theta into account.? That's been fixed in the Help page for LTspice XVII.)

However, LTspice IV's actual behavior differed from this.? Instead of being the steady value given on the Help page (adjusted if necessary if Ncycles is not an integer), it actually shot straight to zero at the end of Ncycles, as you saw.

I would call that a bug in LTspice IV because it clearly doesn't do what the Help says it should have done (for integer Ncycles).

LTspice XVII fixes the bug.

The LTspice XVII Help pages now say, "For times after Ncycles have completed, the voltage (current) is the last voltage (current) when Ncycles have completed.? Note Ncycles does not have to be an integer."? I think that was the intention all along, but LTspice IV was (and is) wrong.

It might be interesting to go back several versions and see if this big appeared at some point or if it was always there.? But I am not currently set up to easily do that.

Regards,
Andy



Re: LTSpive IV vs XVII voltage generators

 

Hello Larry,

I would assume it was done intentionally.? Although there may be arguments for both behaviors, the current behavior seems correct to me.? A simple sine wave is not the only case to consider.? The amplitude may be increasing or decreasing and there may be dc offset.? With all those different cases, having the source just stop at its last value makes the most sense to me.? If going to zero is required, one could always add a pulse source in series with a delay equal to the sine source stop time, a 1ns rise time and a dc value opposite the sine source final value.


---In LTspice@..., <xxw0qe@...> wrote :

I loaded an old circuit that was created in LTspice IV into LTspice XVII today and noticed that the voltage acts differently. Specifying a sine wave voltage source with some number of cycles and some phase so that the ending point is not at 0V the two versions act differently.

Version IV sets all voltage values after the sine wave to 0v where version XVII sets all the values to the last voltage that was specified at the end of the number of cycles.

I assume this was done intentionally or is this possibly an error.

Thanks,
Larry Benko


Re: LTSpive IV vs XVII voltage generators

 

Hello Larry,

I haven't discovered this behavior, because I used sine-burst only a very few times in 17 years. I just checked your reported case and indeed it's different in LTspiceXVII.
It's difficult to say what's better. You can achieve the behavior of LTspiceIV with an additional B-source.

You should report this case to the email address given in the Help->About of LTspiceXVII. Please let us know when you got the answer.

Best regards,
Helmut


Re: How to include component values in LTSpice trace formulas

 

Doug asked:

? ? "I would like to be able to define a trace for the energy stored in a capacitor using the formula E= 1/2 * V^2 * C. But I can't find how to include component values such as capacitance, C, in the trace formulas. Is there a way to do this?"

There is.

First, use .PARAMs to define parameters using those formulas.? This step is not really essential, but it helps to keep things organized.

Then, when you have your (parameter) value calculated, put it within {curly braces}, where the component's value should go.? For example, for a capacitor, right-click on the text where the value would go (originally "C" when you put it on the schematic), and change it to something like {MyCapValue} where MyCapValue is a user-defined parameter that was defined in a .param statement.? Or, I believe you could use {E/(0.5*V(something)**2)}.

Be careful NOT to use "^" to mean exponentiation.? In most places in LTspice, "^" is the operator for XOR.? "**" properly raises one number to an exponent.? See the tables on the Help page for the .PARAM statement.

A pair of curly braces is the way to turn a parameter into a number.? Where SPICE/LTspice expects there to be a number but instead you have a parameter, use curly braces to turn it into a number.

Regards,
Andy



Re: Frequency calc durung trans sim

 

Hello eT,

Have you tried my older eyamples before?

freq_meter_test1.zip, freq_meter_test2.zip

Don't wonder about the small size of characters in these files. When Mike implemented the variable size of characters, he decided to set the text of all older schematics to a minimum size. This has been a really bad decision. You should manually change the size of all text to the new default for better readability.

Best regards,
Helmut


LTSpive IV vs XVII voltage generators

 

I loaded an old circuit that was created in LTSpice IV into LTSpice XVII
today and noticed that the voltage acts differently. Specifying a sine
wave voltage source with some number of cycles and some phase so that
the ending point is not at 0V the two versions act differently.

Version IV sets all voltage values after the sine wave to 0v where
version XVII sets all the values to the last voltage that was specified
at the end of the number of cycles.

I assume this was done intentionally or is this possibly an error.

Thanks,
Larry Benko


Re: Edge triggered b-source logic and integrated averaging in LTspice

 

Hello Vlad,

I noticed that bug and reported it several days ago. Perhaps it would help if you reported it as well. It only is a problem for "B I=" sources that include a defined function and that specify both Rpar and Cpar. Either one alone is okay.


Frequency calc durung trans sim

 

Hi everyone

I'm working on a B device method to calculate the frequency of a square wave during a trans sim.
I'm uploading a file "CalcFreqFromTonToff.zip". Its not a real accurate method but I was hoping
someone could take a look at the schematic and provide thoughts/recommendations?
Appreciate it very much...

thanks

eT


How to include component values in LTSpice trace formulas

 

Just joined the group and don't know how to search whether this has already been addressed - guidance on that would be appreciated!


But here's my question: I would like to be able to define a trace for the energy stored in a capacitor using the formula E= 1/2 * V^2 * C. But I can't find how to include component values such as capacitance, C, in the trace formulas. Is there a way to do this?


Thanks - Doug


Re: Edge triggered b-source logic and integrated averaging in LTspice

 

Hello analogspiceman

These following functions are intended to be used in b-sources. The first
two replicate edge triggered logic such as is used in the a-device DFLOP
clock input. The last function is more complicated as it includes three
behavioral integrators to provide a running integrated average of x
(starting on the falling edge of sampling pulse s) that is then held until
the next rising edge of sampling pulse s. In normal use, x would be an
analog input and the sampling pulse s would be a series of very narrow 1
volt positive digital pulse.

.func up(s) buf( ddt(s)) ; generates pulse on rising edge of s
.func dn(s) buf(-ddt(s)) ; generates pulse on falling edge of s

* The following averages x between sample pulses s
.func ave(x,s) sdt(0,sdt(x,0,dn(s))/sdt(1,0,dn(s)),up(s))

B1 1 0 V= ave(V(x),V(s)) ; source for x and s not shown
It's a nice example on how to use idt() as idt(0, x, y), instead of
the more usual idt(x, 0, y). Still, because we're dealing with
B-sources, I noticed that the output is sensitive to the sampling
clock's time resolution. I tried using a current source with Rpar=1
Cpar=1n to smooth the flow, but apparently I stumbled across a bug:
the simulation won't start and LTspice throws an "Unknown parameter
'1n' [...]". If I don't use the custom function, it works. I tried
with some quick bogus custom functions, and it seems that this only
happens with these, even if the function is x+y. Using any builtin
arithmetic works. Does this happen to you, also? I am using the latest
update (23 oct).

--

Vlad
______________________
ltspicegoodies.ltwiki.org -- holding, among others:
a universal analog/digital filter, block-level models
for power electronics (and not only), math blocks
with a more stream-lined approach, some digital
ADC, DAC, (synchronous-)counter, JKflop, etc.


Re: Edge triggered b-source logic and integrated averaging in LTspice

 

Hello analogspiceman,

Thanks a lot for ths idea of a "sampled" average.

I have made an example with your formulas. Please check my circuit.

I wonder a little bit were the integration really starts and stops compared to the sample clock pulse.

Files > Temp
sampled_average.zip

Best regards,
Helmut


Edge triggered b-source logic and integrated averaging in LTspice

 

Hello all,

These following functions are intended to be used in b-sources.? The first two replicate edge triggered logic such as is used in the a-device DFLOP clock input.? The last function is more complicated as it includes three behavioral integrators to provide a running integrated average of x (starting on the falling edge of sampling pulse s) that is then held until the next rising edge of sampling pulse s.? In normal use, x would be an analog input and the sampling pulse s would be a series of very narrow 1 volt positive digital pulse.

.func up(s) buf( ddt(s)) ; generates pulse on rising edge of s
.func dn(s) buf(-ddt(s))
; generates pulse on falling edge of s

* The following averages x between sample pulses s
.func ave(x,s) sdt(0,sdt(x,0,dn(s))/sdt(1,0,dn(s)),up(s))

B1 1 0 V= ave(V(x),V(s)) ; source for x and s not shown




Re: introduction of a new vacuum tube spice model approach

 

Done!

The generic triode spice model code on the "...for vacuum tubes" page is removed, so a visitors mind should no longer be overloaded.?
Those "native spice speakers" interested in my code will find it in my paper or in the zipped models.?Same to the parameters I listened...
The diagrams are now arranged in a album-style, to further shorten the page.

regards, Adrian


Re: Problems using Pspice fet model for infineon BSR202N.

 

Bordodynov wrote, "but the temperature of the transistor chips is zero, which is not correct."

That happens because of the .TRAN ... STARTUP option, which starts the heatsink temperature at 0 instead of 50.? It takes a while for the junction temperature to catch up, because of the thermal lag of the transistor package internals.

That can be avoided by removing STARTUP.? Who needs it anyway?

I think it could also be avoided by putting the HEATSINK voltage source inside a subcircuit (because I believe STARTUP only affects sources at the top-level).? It can also be avoided by adding this statement:

.IC V(n001)=50 V(n003)=50

but then you really should name those two nodes!? (N001 = Tj of U2, N003 = Tj of U1.)

Regards,
Andy



Re: Problem with inserting components and drawing wires

 

Hello,


I searched a little bit with Google. Maybe this problem has to do with a mouse setting.




You could also try with another mouse.


Helmut


Re: Problems using Pspice fet model for infineon BSR202N.

 

Hi richard.
I made a solution to the problem of calculation, but the temperature of the transistor chips is zero, which is not correct. I do not like these models. To all, due to the complexity may be errors.
See _sbb2_AB.zip in TEMP folder.
?
Bordodynov.


16.11.2018, 09:35, "richard@... [LTspice]" :

?

I think you are right. I made a mistake. Sorry. sbb2.zip in the files area should demonstrate the problem. I will have a look at the help file you have refereed to. I have looked at similar files - and followed their suggestions with cshunt, gshunt, gmin etc without much luck. I agree it is probably a combination of the model and my circuit that is stressing LTspice. I can change out the BSR202N parts for "LTspice native parts" - and the circuit works. Also - Tony's circuit works with the model - so it does appear to be a combination. I'll let you now if I find a solution.


Re: Problems using Pspice fet model for infineon BSR202N.

 

I think you are right. I made a mistake. Sorry. sbb2.zip in the files area should demonstrate the problem. I will have a look at the help file you have refereed to. I have looked at similar files - and followed their suggestions with cshunt, gshunt, gmin etc without much luck. I agree it is probably a combination of the model and my circuit that is stressing LTspice. I can change out the BSR202N parts for "LTspice native parts" - and the circuit works. Also - Tony's circuit works with the model - so it does appear to be a combination. I'll let you now if I find a solution.


Re: introduction of a new vacuum tube spice model approach

 

Hi Andy

Thanks for your detailed response. Tomorrow, I will find time to optimize that. I see now the problem of an overloaded page...?

regards, Adrian


Re: Problems using Pspice fet model for infineon BSR202N.

 

Richard wrote:

? ? "I've uploaded BB2.zip with the circuit, asy and model files."

I think you made a mistake, because there is no BSR202N in that schematic.? Also no "timestep too small" error.? Must be the wrong schematic.

? ? "The main symptom is "Time step too small""

I urge you to download and read the "FAQ" file.? (Hint: It's in the "FAQ" folder in the Files section of the group.)? It has a section about "timestep too small" errors, which unfortunately happen from time to time in all SPICE programs.? There's a chance you can fix the simulation problem yourself.

"Timestep too small" often is not caused by one faulty model.? It's often a combination of things.

Another thing to consider, is using one of the other BSR202N models in Infineon's library file.

BSR202N
BSR202N_L1
BSR202N_L0??

The L1 and/or L0 models might not end up with "timestep too small".? Also, they do not use the 5-pin symbol, so they do not include dynamic die temperature rise, which may or may not be an issue for you.? You could do the simulation at a higher SPICE temperature (or just set that MOSFET to the higher temperature), which is fine except that it keeps the temperature constant over time.

Regards,
Andy



Re: Behavioral source timestep limits ?

 

There are contradiction in real world ,too. If I just only study the textbook which contain lots math equations to describe the phenomemon of physics/electrics, etc. I tend to be confused, but if I just do the works ,practices of physical effort, I couldn't understand more deep theoretical mechanism behind, and unfortunately I, for an only one instance existing, I couldn't be two or more instances existing instantaneously to learn theory in the meanwhile do the practical things, and then connect them, so the fundamental materials is important, which is somewhat similar to , sometimes, we need to do FFT to transfer the time domain things to frequency domain, then revert the frequency domain things to time domain, make things simpler/clear to see, though the process is more complicated.

By the way, I really had suffered severe math equations confusion very badly, before . But, I still believe the learning curve of based on the basis/fundamental things ,finally would be likely the exp effect. Though, I don't think it's very impressive (I don't feel that / think so) , about the time step, but if you doubt or misunderstand.

Best regards.

---In LTspice@..., <ericsson.sunshine@...> wrote :

Hello, Andy:

The mentioned ideas was not from me, and not related to what I said about 'confidential'. Just a brief, sudden thoughts, but I certainly remembered that someone who had written some thing about that (I surveyed that years ago) , though not very detailed about implementation. I guess its phase is not from detection, I would presume it's from pre-calculation, since many parameters could be obtained, Irms, Vrms, jwC, jwL, etc. Then generate whatever signal to the input of the compensation. The last thing is about the math & equations of math in the nature/circuits.

I know some of the rule of the nature, and some culture of some countries, but the world is huge, I don't understand everything, including rules everywhere and nowhere. But if possible, I would like keep going further, not for any matters, maybe for fun, I think.

Thank you very much.


---In LTspice@..., <ai.egrps@...> wrote :

I still don't know what the Bv is for.

Since it represents an unreal component, are you thinking about using it to experiment with an altered circuit, before designing that "alteration" using real components?? Or do you want to add an extra signal into your circuit?? Otherwise, I can't imagine why a Bv would be a useful thing, here.

Regardless of the reason, you need to be more careful to consider the effect of adding the Bv to the existing circuit.? In both examples, it has a profound effect even though it is only a unity-gain buffer.? Remember that Bv unity-gain buffers have infinite input impedance and zero output impedance and are uni-directional, so breaking a connection and inserting a Bv source in its place, is a significant change.

I don't know whether the following might be useful.? But a simple Bv unity-gain buffer could be replaced by a unity-gain E-element.? As far as I know, E-elements do not have the restrictions that a Bv source might have.? Therefore, if you were concerned about those Bv-source restrictions, you could replace it by an E-element.? While it is true that LTspice sometimes elevates an E-element back to a B-element, I think that it does not for a simple linear buffer.? So, you could use an E-element to check whether changes to your simulations were due to Bv-source's peculiar limitations, or something else.

Regards,
Andy