2
\$\begingroup\$

I am simulating somewhat complex behavioral sources in LTspice - and am having difficulty getting a set of parameters to be accepted. See schematic below of a bidirectional buck/boost converter. I think it is rejecting my ".param D=..." line because it contains the table parameters. Can anyone give me a suggestion on how to resolve this? I need to "pre-calculate" the D parameter based on the step values of V1 and V2. If I just define V1 and V2 with no step/table , the simulation works fine.

Thanks for any suggestions!

enter image description here

\$\endgroup\$
1
  • \$\begingroup\$ I have not used a lot of parameter stepping, but the best I can suggest here is that you do as much pre-calculation as you can, but define the expressions for your B sources in terms of Vx, or define sources generating voltages at nodes called V1 and V2, and use these in the expressions in the B sources. I think all the terms using in param expressions have to be known constants at the start of the simulation, yours are only constant within each step. \$\endgroup\$ – user1582568 Feb 11 '16 at 17:19
1
\$\begingroup\$

In LTspice, and not only, conditional expressions like if() tend to introduce discontinuities which go against the solver because of the derivative in that point. Some simple discontinuities may be avoided, but, usually, they are to be avoided.

One solution would be to try to smooth out the discontinuity by adding a small capacitor (fF~pF) across the source that has the conditionals, which would force the waveform to follow a more fluid path, thus allowing the solver to "see" all the points and go past it, while, at the same time, not influence the circuit by introducing unwanted poles that could cause wrong results.

Another solution would be to simply use the A-devices that come with LTspice, or, with the newer LTspice XVII, the .machine command. I say this by looking at your schematic, where I see, mostly, cases of if(cond, <one_voltage>, <another_voltage>), which can easily be solved with logic gates.

While we're at it, you could also avoid the positive hysteresis for the switch, which is known for causing trouble, and choosing a negative value, which would make the transitions go smoothly from on to off and vice-versa, instead of abrupt changes.

Another minor note would be to not rely on the default diodes, which are ideal, and either force a "normal" diode by specifying one of the other parameters, like Is=1f, for example. Or, you could keep the faster ideal diode, but it won't hurt adding epsilon=<fraction of Vfwd> and revepsilon=<fraction of Vfwd> -- they add a simple quadratic region to the knee(s) of the transfer function.

And, finally, parasitics in Cs and Ls can go a long way in both avoiding very large switched quantities (currents, mostly), and in making the circuit behave more real.

\$\endgroup\$
1
  • \$\begingroup\$ I forgot to add that behavoural sources, while extremely versatile, are not quite reliable because of this. They are also time dependent and every point will be calculated during runtime (for anything time related), which can be a burden. Whenever you can, replace them with primitive elements. \$\endgroup\$ – a concerned citizen Sep 6 '16 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.