7
\$\begingroup\$

When I'm loading PWL files into a voltage source or a current source, I'm not getting what is provided in PWL file content. I'm attaching three pictures to show file content, schematic and plot.

In a PWL file I've tried to change a format and values of a few entries to exclude some possible issues, but to no avail.

I've started from a file with much smaller values and a bit more of significant digits (2.0050101 to 2.0161231). I thought that it might be a precision issue, so I've increased values and removed number of significant digits. Slightly different behavior, but still wrong results.

Why is LTspice not interpreting it as it should, and how can I fix it? I was googling for the specification of PWL, but nothing related came up :/

I'm also presenting special characters, so that formatting is clear.

Enter image description here

On the plot in green is a measured value and in red is what I would expect to see.

Enter image description here

Schematic

Enter image description here

\$\endgroup\$

4 Answers 4

11
\$\begingroup\$

The reason you see it like this is because you are using a very high dynamic range for the values: time points in the range of hundreds of thousands (1e5) coupled with values that vary in the range of hundreds of microvolts (1e-4)! Due to the compression algorithm the display of the waveform appears distorted. The solution is to add .opt plotwinsize=0. Be careful as the .RAW file may grow very large now. The .save command will help if that's the case.

\$\endgroup\$
6
  • \$\begingroup\$ Hi a concerned citizen, that's worked like a charm :). One thing I had to change, are data points with same time stamp. I had to change them a bit to differ by 1 sec., otherwise LtSpice is removing entries with the same timestamp - at least it seems like it \$\endgroup\$
    – Bart
    Nov 17, 2021 at 7:59
  • 1
    \$\begingroup\$ @Bart The timepoints must be in a strictly increasing order, but there is a shortcut that can help you. For example if you need a 1 sec edge near a 20 kilosecond value, you can write it like this: ... 20k 0.7 +1 0.8 ... (the data points are random). This tells the engine that the first time point is at 20 kiloseconds and the next one is incremented by 1 second relative to the previous, thus 20.001 kiloseconds. As usual, there's no need to exaggerate with sharp edges: using a 1,000x...10,000x times smaller rising/falling edge is enough in most of the cases, otherwise the engine needs to ... \$\endgroup\$ Nov 17, 2021 at 9:50
  • 1
    \$\begingroup\$ ... drastically reduce the timestep and that may or may not cause hiccups. Also, LTspice is spelled with the first two letters capitalized. \$\endgroup\$ Nov 17, 2021 at 9:51
  • 1
    \$\begingroup\$ thank you for additional comment. That is actually very useful to reduce file size. My file started to look like below, which unnecessarily increases size. Now i will update the code and have +3.6k or +43.2k or something like that. * 29.4264Meg 100 * 29.429999Meg 100 \$\endgroup\$
    – Bart
    Nov 17, 2021 at 11:51
  • 1
    \$\begingroup\$ @Bart If this did the trick (and/or you think it's the best answer), then please accept it or whichever one you think is best. \$\endgroup\$
    – Ste Kulov
    Nov 18, 2021 at 6:50
3
\$\begingroup\$

Use a "sample" device as shown for the staircase like pattern. Adjust clk frequency according to your x-axis values.

enter image description here

\$\endgroup\$
2
\$\begingroup\$

Works ok for me, enter image description here

Here's how I formatted the .txt file. Notice I used t,v not v t . Also, your table does not seem to hold the same step values for long periods as in your drawing. .trans 2Meg seems incredibly long for a transient response.

0,0
1e-04,0
2e-04,0
3e-04,0
4e-04,0
...
0.9991,6
0.9992,6
0.9993,6
0.9994,6
0.9995,6
0.9996,6
0.9997,6
0.9998,6
0.9999,6
1,6

If you similarly attach a sample of your table in code tags, I can try to replicate on my end.

\$\endgroup\$
4
  • 2
    \$\begingroup\$ While this may work it seems terribly inefficient, to use that many data-time points just to simulate the "flat" part. \$\endgroup\$ Nov 15, 2021 at 19:59
  • \$\begingroup\$ Agree, though pretty easy to down-sample the raw data file if that's an issue. Just a matter of how the data is generated. \$\endgroup\$
    – pat
    Nov 15, 2021 at 20:09
  • \$\begingroup\$ @pat I generate data from C# code so, it wouldn't be an issue but just adding ".opt plotwinsize=0" works good, so i don't need to change the code and file size is way smaller. \$\endgroup\$
    – Bart
    Nov 17, 2021 at 8:04
  • \$\begingroup\$ Yep. Because changing that setting allow LTspice to do the downsampling for you. Either way works fine. \$\endgroup\$
    – pat
    Nov 17, 2021 at 20:26
1
\$\begingroup\$

You are letting LTspice select its own time step in the transient analysis. You need to force the maximum timestep in your .tran statement to 1, or smaller; or whatever the your granularity of your time steps are.

\$\endgroup\$
3
  • \$\begingroup\$ This has gotten me before as well - just because you have a step in your PWL does not mean that the simulator is obligated to evaluate at that time. \$\endgroup\$
    – W5VO
    Nov 16, 2021 at 14:40
  • 1
    \$\begingroup\$ @W5VO Actually, SPICE is specifically designed to do just that, and it does. They're called "breakpoints" in the documentation. \$\endgroup\$
    – Ste Kulov
    Nov 16, 2021 at 16:41
  • \$\begingroup\$ @SteKulov Maybe it was an actual bug or edge case since I was using a repeated PWL - the repeated segments weren't getting executed. Not LTSPICE, but relaying a similar experience. \$\endgroup\$
    – W5VO
    Nov 16, 2021 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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