Hello
I am testing to do a step analysis on a FRA analysis of a simple RC circuit. I want to use this later on a dc-dc converter. I am stepping two values of the capacitor 100nF and 10 nF.
The results of the text file seem ok. However, when doing the plotting it seems that Qspice only represents the results of one of the values of Cf.
Any idea?
Thanks very much!
RC-circuit-FRA-test-step-on-Cf.qsch (3.5 KB)
A quick verify, change the order of freq and Cf. In general, I put x-axis quantity in first sweep. What I don’t understand is why x-axis quantity in your original .step sequence is also freq instead of Cf.
.step dec param freq 100 100K 10 param Cf list 100n 10n
Thank you very much. That works.
You won’t believe but I also considered inverting the order of the parameters but I dismissed the idea because it seemed to me that it wouldn’t work either …
Thanks!
Hi Marcos and Kelvin,
Just accidentally run the dicussed simulation and found I cannot get the curves you had. My result:
It appears that the issue started with the build from the 19-Oct. I have just submitted this case to Mike for review.
It seems the solution can only be fixing Tstart when .meas is used. Attached is a modification that should work. The downside is that the data file (.qraw) will be larger as more data is saved.
Hi Kelvin,
Thanks for your always helpful support!
Best regards
Yi
@marcos.uniovi This update allows waveform viewer to keep track of .step with parameterized Tstart where the time not always goes backward between step.
Here upload the schematic for your reference, and as a result, for previous Fix Tstart to work, it requires to revert to the former behavior with .option absolutetime=1 added.
RC-circuit-FRA-test-step-on-Cf (Tstart Parameterized).qsch (3.3 KB)
RC-circuit-FRA-test-step-on-Cf (Fix Tstart) - Enable absolutetime.qsch (3.3 KB)
Hello, thanks for the information.
I do not see the point. It seems to me the same way I did before
This was the situation before: the simulation produced strange results, appearing as if a data point was missing. The issue lies in the fact that the waveform viewer depends on time moving backward to track each step. If Tstart in .tran is a step parameter, it cannot ensure that time moves backward in every step. Consequently, the waveform viewer struggles to differentiate the steps accurately, potentially leading to merged steps.
This is an explanation of what this update brings us. I remember your case as one example where we had to use a fixed Tstart to achieve a perfect result before this update.
Before this update, for a .tran with Tstart, time begin with Tstart in time-axis. Now, it set time to 0s and behave likes LTspice. You can control this characteristic with .option absolutetime
I understand now.
Thank you very much!
