Activity for ngspice
-
Kevin Faison modified a comment on discussion ngspice-users
That works like a charm! I am still ramping on NGspice Here is the snippet I used, .control save v(out2) iplot -w 5u -d 4000 v(out2) .endc The pic is a screen shot of ngspice actively simulating with a marching waveform, v(out2). The total sim time is 500uS with the plot window width = 5uS. Thanks Again! Kevin!
-
That works like a charm! I am still ramping on NGspice Here is the snippet I used, .control save v(out2) iplot -w 5u -d 4000 v(out2) .endc The pic is a screen shot of ngspice actively simulating with a marching waveform, v(out2). The total sim time is 500uS with the plot window width = 5uS. Thanks Again! Kevin![] (https://drive.google.com/file/d/1IQwrZizY4MBO7UtOLZSpRYq1qyEGwoCh/view?usp=sharing)
-
That works like a charm! I am still ramping on NGspice Here is the snippet I used, .control save v(out2) iplot -w 5u -d 4000 v(out2) .endc The pic is a screen shot of ngspice actively simulating with a marching waveform, v(out2). The total sim time is 500uS with the plot window width = 5uS. Thanks Again! Kevin
-
Thank you Marcel and Holger, will be giving this a go in next day or two! Warm Regards, Kevin
-
geraldfournier posted a comment on ticket #837
On second thought, the current behavior is consistent with the convention adopted by ngspice, which is to normalize results to match the signal amplitude. This means applying an ACF (Amplitude correction factors) in conjunction with windows which renormalizes the peak values to match signal amplitude. I've identified two other small bugs/issues wrt FFT windowing in ngspice, but they are somewhat subtle and have only a minor effect on numerical results. Since attempts to fix bugs here have been SO...
-
ga committed [c70490] on ngspice-manuals
Enrique Corpa added the nperiods variable to the fourier/.four commands.
-
ga committed [691457] on ngspice-manuals
Fix broken references to XSPICE hybrid models.
-
ga committed [b90aad] on ngspice-manuals
Move description of cvector() to the table of utility vector functions.
-
Holger Vogt modified a comment on discussion ngspice-users
Example: https://sourceforge.net/p/ngspice/ngspice/ci/master/tree/examples/xspice/pll/pll-xspice-fstep.cir Move to or download https://sourceforge.net/p/ngspice/ngspice/ci/master/tree/examples/xspice/pll/, then run ngspice pll-xspice-fstep.cir
-
Example: https://sourceforge.net/p/ngspice/ngspice/ci/master/tree/examples/xspice/pll/pll-xspice-fstep.cir
-
marcel hendrix posted a comment on discussion ngspice-users
Manual 13.5.43 Iplot*: Incremental plot .
-
Greetings ngspice folks, From another application I am able to launch the ngspice gui with my spice netlist and start the simulation. That all works great. Now I would like to start the sim and have ngspice immediately begin plotting the output of a voltage node so I can monitor the shape of the waveform. This is so I dont have to wait until the sim completes before knowing if a problem occurred. Is this possible? Right now, I open a cmd shell and execute line something like this, ngspice -b -r adder.raw...
-
Although this change would produce agreement with Xyce, It seems like Xyce has a different convention. That's why they might agree with window=rect, after recent fixes, but perhaps should not agree when a window is applied. The ngspice 45 manual says: All window functions have a rms value of 1. That means: No amplitude correction for the result is needed after applying the functions to the time domain input signal. And I don't think Xyce makes the same choice. So i'm putting this issue on hold until...
-
Although this change would produce agreement with Xyce, It seems like Xyce has a different convention. That's why they might agree with window=rect, after recent fixes, but perhaps should not agree when a window is applied. The ngspice 45 manual says: All window functions have a rms value of 1. That means: No amplitude correction for the result is needed after applying the functions to the time domain input signal. And I don't think Xyce makes the same correction. So i'm putting this issue on hold...
-
Although this change would produce agreement with Xyce, It seems like Xyce has a different convention. That's why they might agree with window=rect, after recent fixes, but perhaps should not agree when a window is applied. The ngspice 45 manual says: All window functions have a rms value of 1. That means: No amplitude correction for the result is needed after applying the functions to the time domain input signal. And I don't think Xyce makes the same correction. So i'm putting this issue on hold...
-
Holger Vogt committed [1c0bc1] on ngspice
make fft scaling independent from rounding behaviour for odd data
-
Holger Vogt committed [32e0d5] on ngspice
Revert "make fft scaling independent from rounding behaviour for odd data"
-
No need to rewrite git history. Please be more careful in the future. I'll rebase future patches as needed.
-
The original bug report by Marcel/Federico is correct, and the changes made in 2017 did not address it. The example given by Federico generates 64 points with a tstep of 0.0625m, and should indeed result in a frequency resolution of 250Hz. This has finally been fixed just recently in the pre-master-46 branch via #829 and via bfe496937. More FFT bugs related to normalization errors have been fixed via #834 and #835. Bugs regarding the use of windows with FFT are still present, with #837 as the initial...
-
The original bug report by Marcel/Federico is correct, and the changes made in 2017 did not address it. The example given by Federico generates 64 points with a tstep of 0.0625m, and should indeed result in a frequency resolution of 250Hz. This has finally been fixed just recently in the pre-master-46 branch via #829 and via bfe496937. More FFT bugs related to normalization errors have been fixed via #834 and #835. Bugs regarding the use of windows with FFT are still present, with #837 as the initial...
-
yahia ghadiry posted a comment on ticket #104
@h_vogt I have done some debugging and found out the reason hsa didn't work for me with, sky. It turns out it doesn't have to do with the sky but the "bugginess" I was taking about. If I have a mosfet defined as ex: .param WIDTH=1 LENGTH=2 NF=3 MULT=4 M0 v1 v2 v3 v4 nmos w=WIDTH l={LENGTH} nf='NF' m='{MULT}' as=' 5 * WIDTH' ad=' 6 * {WIDTH}' The previouse example code will run with both hsa and no hsa in ngspice44, but in ngspice45+ this will only work without hsa enabled, as the following two will...
-
Dietmar Warning modified a comment on ticket #835
I see on other computer that my reset and push --force has not brought the result even it was shown as successful. May be we can change it by cherry pick from pre-master to master. Normally the contributors work with own branches and make merge request's. That would be more safe and comfortable.
-
I see on other computer that my reset and push --force has not brought the result even it was shown as successful. May be we can change it by cherry pick from pre-master to master. Normally the contributors work with own branches and make PR. That would be more safe and comfortable.
-
Thank you, I believe it was just an honest mistake. Please be more careful about giving proper credit in the future. There's little reward in doing free open-source work except credit.
-
it looks as if 8aa20cfc9 was trying to normalize the peak of the windows to a value of 1, which is incorrect.
-
Please generate an new patch next time from pre-master-46. I just resetted.
-
No, I tried git apply and git am but both failed for unknown reasons. Perhaps a crossing with my commits the patch was not synchronize. I will try to revert or editing the commit.
-
FFT windows are incorrectly scaled
-
dwarning, although I'm certainly glad you've started to use my patches, can you explain why you keep committing my patches and the fixes I identify under your own name rather than mine? it looks like you are taking credit for my work. Why?
-
For example, In the future, I would also like to add a "keep_points=1024" argument to linearize, which truncates the linearized vector to a desired number of points. When choosing parameters for bandwidth and frequeny resolution, it's sometimes convenient to use np= (which calculates a newtstep) and sometimes to choose a tstep and then truncate to a specific number of points. Both approaches are valid and useful. I'm willing to take care of writing the docs, if linearnp is folded into linearize
-
Consider replacing new linearnp command with "linearize np=xxx"
-
I confirm that a31ac5420 fixed this issue.
-
make fft scaling independent from rounding behaviour for odd data
-
dick freebird posted a comment on discussion Help
A very simple method is to place two subcircuits and run them with opposite direction ramps using controlled and independent fixed sources from a single "sweep source".
-
Please revert b522bcc6c, and apply the patch I provided and tested.
-
Commit b522bcc6c correct Nyquist bin scaling for Green branch dwarning does not fix the bug. I provided a tested patch - which you didn't use. I provided a test for verifying the fix - which you didn't use to check your own fix. Why? You also labeled the fix as concerning the Green branch, when reality is that only FFTW has support for odd FFT.
-
correct Nyquist bin scaling for Green branch
-
This only applies to odd FFT.
-
FFT normalization of regular (non-DC/nyquist) bins is wrong.
-
I confirm that ad44b4ff4 fixed this issue, others remains.
-
Merge branch 'pre-master-46' of ssh://git.code.sf.net/p/ngspice/ngspice into pre-master-46
-
let nyquist bin not empty for odd vector
-
SFFM parameter order not correct
-
Fixed in pre-master-46
-
Holger Vogt committed [5855c4] on ngspice
FM and FC exchange place in the parameter sequence of SFFM voltage
-
Frequency resolution is 1 / simulation time and independent from FFT point number. To answer precise to the question above I am missing math skills as the TO stated often. But e.g. .tran 0.1u 100u will have 10kHz in result file as fundamental and step frequency and not 9.9989kHz or something else. Thank you for answering, and for acknowledging some level of uncertainty about the mathematical details. Your answer of 10Khz is wrong, from both math definition perspective and as proper testing shows....
-
Frequency resolution is 1 / simulation time and independent from FFT point number. To answer precise to the question above I am missing math skills as the TO stated often. But e.g. .tran 0.1u 100u will have 10kHz in result file as fundamental and step frequency and not 9.9989kHz or something else. Thank you for answering, and for acknowledging some level of uncertainty about the mathematical details. Your answer of 10Khz is wrong, from both math definition perspective and as proper testing shows....
-
To clarify, d2b1ecbb2 fixed even case and broke odd case. And subsequent a0dc0bb60 put even case behind a conditional but left odd case empty. Restoring the loop limit will get both right. Here are the test netlists.
-
To clarify, d2b1ecbb2 fixed even case and broke odd case. And subsequent a0dc0bb60 put even case behind a conditional but left odd case broken. Restoring the loop limit will get both right. Here are the test netlists.
-
To clarify, d2b1ecbb2 fixed even case and broke odd case. And subsequent a0dc0bb60 put even case behind a conditional but left odd case broken. Restoring the loop limit will get both right. Here are the test netlists.
-
To clarify, d2b1ecbb2 fixed even case and broke odd case. And subsequent a0dc0bb60 put even case behind a conditional but left odd case broken. Fixing the loop will get both right. Here are the test netlists.
-
To clarify, d2b1ecbb2 fixed even case and broke odd case. And subsequent a0dc0bb60 put even case behind a aconditional but left odd case broken. Fixing the loop will get both right. Here are the test netlists.
-
I confirm that 6ae057b3e fixed this issue. Can close. Thanks.
-
To clarify, d2b1ecbb2 fixed odd case and broke even case. And subsequent a0dc0bb60 fixed even case and broke odd case. Fixing the loop will get both right. Here are the test netlists.
-
Normalization of last bin is incorrect
-
Sorry, I'll put that in a new ticket.
-
Removed
-
-
The fix in a0dc0bb60 is incorrect. Now the last bin value is properly normalized in the even FFT (length%2==0) case , but empty in the odd FFT case. This change from d2b1ecbb2 needs to be undone: - for (i = 1; i < fpts; i++) { + for (i = 1; i < fpts-1; i++) { it should be fpts. The loop should fill and normalize all bins (except DC) including outdata[fpts-1]. Then, in the even case, the value in outdata[fpts-1] should be overwritten with the correct normalized value for the nyquist bin. Here are...
-
The fix in a0dc0bb60 is incorrect. Now the last bin value is properly normalized in the even FFT (length%2==0) case , but empty in the odd FFT case. This change from d2b1ecbb2 needs to be undone: - for (i = 1; i < fpts; i++) { + for (i = 1; i < fpts-1; i++) { it should be fpts. The loop should fill and normalize all bins (except DC) including outdata[fpts-1]. Then, in the even case, the value in outdata[fpts-1] should be overwritten with the correct normalized value for the nyquist bin. Here are...
-
The fix in a0dc0bb60 is incorrect. Now the last bin value is properly normalized in the even FFT (length%2==0) case , but empty in the odd FFT case. This change from d2b1ecbb2 needs to be undone: - for (i = 1; i < fpts; i++) { + for (i = 1; i < fpts-1; i++) { it should be fpts. The loop should fill and normalize all bins (Except DC) including outdata[fpts-1]. Then, in the even case, the value in outdata[fpts-1] should be overwritten with the correct normalized value for the nyquist bin. Here are...
-
The fix in a0dc0bb60 is incorrect. Now the last bin is properly normalized in the even FFT (length%2==0) case , but empty in the odd FFT case. This change from d2b1ecbb2 needs to be undone: - for (i = 1; i < fpts; i++) { + for (i = 1; i < fpts-1; i++) { it should be fpts. The loop should fill and normalize all bins (Except DC) including outdata[fpts-1]. Then, in the even case, the value in outdata[fpts-1] should be overwritten with the correct normalized value for the nyquist bin. Here are test cases...
-
The fix in a0dc0bb60 is incorrect. Now the last bin is properly normalized in the even case , but empty in the odd case. This change from d2b1ecbb2 needs to be undone: - for (i = 1; i < fpts; i++) { + for (i = 1; i < fpts-1; i++) { it should be fpts. The loop should fill and normalize all bins (Except DC) including outdata[fpts-1]. Then, in the even case, the value in outdata[fpts-1] should be overwritten with the correct normalized value for the nyquist bin. Here are test cases for both even (Same...
-
The fix in a0dc0bb60 is incorrect. Now the last bin is properly normalized in the even case , but empty in the odd case. This change from d2b1ecbb2 needs to be undone: - for (i = 1; i < fpts; i++) { + for (i = 1; i < fpts-1; i++) { it should be fpts. The loop normalizes all bins, including outdata[fpts-1], and in the even case, the value in the bin is overwritten with the correct normalized value for the nyquist bin. Here are test cases for both even (Same as above) and odd FFT.
-
The fix in a0dc0bb60 is incorrect. Now the last bin is properly normalized in the even case , but empty in the odd case. This change from d2b1ecbb2 needs to be undone: - for (i = 1; i < fpts; i++) { + for (i = 1; i < fpts-1; i++) { it should be fpts. The loop normalizes all bins, including outdata[fpts-1], and in the even case, the value in the bin is overwrriten with the correct normalized value for the nyquist bin. Here are test cases for both even (Same as above) and odd FFT.
-
The fix in a0dc0bb60 is incorrect. Now the last bin is properly normalized in the even case , but empty in the odd case. This change from d2b1ecbb2 needs to be undone: - for (i = 1; i < fpts; i++) { + for (i = 1; i < fpts-1; i++) { it should be fpts. The loop normalizes all bins, including outdata[fpts-1], and in the even case, the value is overwrriten with the correct expression. Here are test cases for both even (Same as above) and odd FFT.
-
The fix in a0dc0bb60 is incorrect. Now the last bin is properly normalized in the even case , but empty in the odd case. This change from d2b1ecbb2 needs to be undone: - for (i = 1; i < fpts; i++) { + for (i = 1; i < fpts-1; i++) { it should be fpts (ok, since there are fpts+1 points in the array). The loop normalizes all bins, including outdata[fpts-1], and in the even case, the value is overwrriten with the correct expression. Here are test cases for both even (Same as above) and odd FFT.
-
The fix in a0dc0bb60 is incorrect. Now the last bin is properly normalized in the even case , but empty in the odd case. This change from d2b1ecbb2 needs to be undone: - for (i = 1; i < fpts; i++) { + for (i = 1; i < fpts-1; i++) { it should be fpts (theere are fpts+1 points in the array). The loop normalizes all bins, including outdata[fpts-1], and in the even case, the value is overwrriten with the correct expression. Here are test cases for both even (Same as above) and odd FFT.
-
The fix in a0dc0bb60 is incorrect. Now the last bin is properly normalized in the even case , but wrong in the odd case. This change from d2b1ecbb2 needs to be undone: - for (i = 1; i < fpts; i++) { + for (i = 1; i < fpts-1; i++) { it should be fpts (theere are fpts+1 points in the array). The loop normalizes all bins, including outdata[fpts-1], and in the even case, the value is overwrriten with the correct expression. Here are test cases for both even (Same as above) and odd FFT.
-
Special Nyquist scaling only for even length
-
revert commit 5e82b63
-
This ticket can be closed now. bfe496937 has been committed to pre-master-46, and it resolves the original bug I reported regarding the FFT frequency labels and frequency resolution being wrong (well, it will be once #833 is fixed). I will open other tickets to address the other bugs found during this discussion, as well as new bugs introduced by other attempted fixes.
-
Frequency resolution is 1 / simulation time and independent from FFT point number. To answer precise to the question above I am missing math skills as the TO stated often. But e.g. .tran 0.1u 100u will have 10kHz in result file as fundamental and step frequency and not 9.9989kHz or something else. Thank you for answering, and for acknowledging some level of uncertainty about the mathematical details. Your answer of 10Khz is wrong, from both math definition perspective and as proper testing shows....
-
Frequency resolution is 1 / simulation time and independent from FFT point number. To answer precise to the question above I am missing math skills as the TO stated often. But e.g. .tran 0.1u 100u will have 10kHz in result file as fundamental and step frequency and not 9.9989kHz or something else. Thank you for answering, and for acknowledging some level of uncertainty about the mathematical details. Your answer of 10Khz is wrong, from both math definition perspective and as proper testing shows....
-
FFT places undefined value in last bin
-
I think you've overlooked the fact that in order to match the 1024 point FFT in the Xyce example, the ngspice netlist only uses the first 1024 points from the linearized simulation. Ensuring the same number of points is necessary for a proper test against Xyce/numpy. You can change the tran 50m to 75.3m or 12456s or anything >49.9511719ms in intermod_ngspice.cir, and you will always get the same result - because the additional points are simply thrown away. No additional changes to the gf_fft_scale...
-
Here are test files which shows good agreement between the fft output generated by my patches and the equivalent fft output from Xyce and numpy (uses ngspice commit 5610302c7 in the gf_fft_scale branch). They adapt the intermod example provided by Dietmar, which is a very good test case since it includes 12 frequencies with varying amplitudes. Unlike previous tests by others in the thread, that rely on either visual plots or approximate comparisons at only specific bins, these tests ensure: The SAME...
-
Here are test files which shows good agreement between the fft output generated by my patches and the equivalent fft output from Xyce and numpy (uses ngspice commit 5610302c7 in the gf_fft_scale branch). They adapt the intermod example provided by Dietmar, which is a very good test case since it includes 12 frequencies with varying amplitudes. Unlike previous tests by others in the thread, that rely on either visual plots or approximate comparisons at only specific bins, these tests ensure: The SAME...
-
I think you've overlooked the fact that in order to match the 1024 point FFT in the Xyce example, the ngspice netlist only uses the first 1024 points from the linearized simulation. Ensuring the same number of points is necessary for a proper test against Xyce/numpy. You can change the tran 50m to 75.3m or 12456s or anything >49.9511719ms in intermod_ngspice.cir, and you will always get the same result - because the additional points are simply thrown away. No additional changes to the gf_fft_scale...
-
Here are test files which shows good agreement between the fft output generated by my patches and the equivalent fft output from Xyce and numpy (uses ngspice commit 5610302c7 in the gf_fft_scale branch). They adapt the intermod example provided by Dietmar, which is a very good test case since it includes 12 frequencies with varying amplitudes. Unlike previous tests by others in the thread, that rely on either visual plots or approximate comparisons at only specific bins, these tests ensure: The SAME...
-
Here are test files which shows good agreement between the fft output generated by my patches and the equivalent fft output from Xyce and numpy (uses ngspice commit 5610302c7 in the gf_fft_scale branch). They adapt the intermod example provided by Dietmar, which is a very good test case since it includes 12 frequencies with varying amplitudes. Unlike previous tests by others in the thread, that rely on either visual plots or approximate comparisons at only specific bins, these tests ensure: The SAME...
-
I think you've overlooked the fact that in order to match the 1024 point FFT in the Xyce example, the ngspice netlist only uses the first 1024 points from the linearized simulation. Ensuring the same number of points is necessary for a proper test against Xyce/numpy. You can change the tran 50m to 75.3m or 12456s or anything >49.9511719ms in intermod_ngspice.cir, and you will always get the same result - because the additional points are simply thrown away. No additional changes to the gf_fft_scale...
-
Holger Vogt committed [8639a0] on ngspice
Enable linearizing all vectors, when none is given, with or without np statement.
-
Holger Vogt committed [bfe496] on ngspice
Add patch for span
-
I think you've overlooked the fact that in order to match the 1024 point FFT in the Xyce example, the ngspice netlist only uses the first 1024 points from the linearized simulation. Ensuring the same number of points is necessary for a proper test against Xyce/numpy. You can change the tran 50m to 75.3m or 12456s or anything >49.9511719ms in this script, and you will always get the same result because the additional points are simply thrown away. No additional changes to the gf_fft_scale branch were...
-
If you meant this circuit gives 20Hz frequency resolution with YOUR changes to pre-master, that's ok, but you haven't addressed all the issues I pointed out with them. And the fft(length-1) approach seems unworkable to me. We could combine my patches with something like your linearnp command to make things more convenient for future users, but first we need to ensure existing linearize+fft netlists return the correct results.
-
If you meant these files gives 20Hz frequency resolution with YOUR changes to pre-master, that's ok, but you haven't addressed all the issues I pointed out with them. And the fft(length-1) approach seems unworkable to me. We could combine my patches with something like your linearnp command to make things more convenient for future users, but first we need to ensure existing linearize+fft netlists return the correct results.
-
I think you've overlooked the fact that in order to match the 1024 point FFT in the Xyce example, the ngspice netlist only uses the first 1024 points from the linearized simulation. Ensuring the same number of points is necessary for a proper test against Xyce/numpy. You can change the tran 50m to 75.3m or 12456s or anything >50m in this script, and you will always get the same result because the additional points are simply thrown away. No additional changes to the gf_fft_scale branch were made....
-
I think you've overlooked the fact that in order to match the 1024 point FFT in the Xyce example, the ngspice netlist only uses the first 1024 points from the linearized simulation. Ensuring the same number of points is necessary for a proper test against Xyce/numpy. You can change the tran 50m to 75.3m or 12456s or anything >50m in this script, and you will always get the same result because the additional points are simply thrown away. No additional changes to the gf_fft_scale branch were made....
-
Here are test files which shows good agreement between the fft output generated by my patches and the equivalent fft output from Xyce and numpy (uses ngspice commit 5610302c7 in the gf_fft_scale branch). They adapt the intermod example provided by Dietmar, which is a very good test case since it includes 12 frequencies with varying amplitudes. Unlike previous tests by others in the thread, that rely on either visual plots or approximate comparisons at only specific bins, these tests ensure: The SAME...
-
Alberto Brunero posted a comment on discussion Help
Thank you Holger, my bad, I thought that the dc sweep would use the previous dc point as the starting point for calculating the next one. Is there any way to force ngspice to do the dc sweep in such a way? Like loading automatically the .ic file of the previous one, or maybe using something like wrnodev? Sorry, I am still quite new to using ngspice.
-
Wow - tran 50ms statement now brings 20Hz frequency steps! Under this requirement we can go further - if you like. Can you please provide a diff to branch gf_fft_scale. I will play it in and make my checks.
-
Justin Fisher posted a comment on discussion Help
Even without the prior state the hysterisis can't show you, the trip point in a DC sweep is going to be somewhere near the 2 trip points. You'll never see it in transient though, because 500us is far to fast. Your quite sure though, so please go ahead, flail around, and ask design related questions instead of simply running a sensible simulation. -- Kind regards, Justin Fisher. On Mon, Mar 2, 2026, 11:48 Holger Vogt h_vogt@users.sourceforge.net wrote: A circuit with hysteresis has an input range...
-
A circuit with hysteresis has an input range which may yield (two) different outputs, depending on the history. Thus you cannot use dc to simulate such a bistable circuit, as the history is not defined unambiguously.
-
However it is totally sensitive to the fft window. Any other immediately worsens the result. Is this a very special example? Yes, it's a very special case called "coherent sampling". Only in such cases does a rectangular window give exact results. coherent sampling reqiures the simulation time to capture exactly a whole number of signal periods. In such cases, other window smear the energy to surrounding bins as you can see. This behavior is normal and universal, and exists in every FFT implementation....
-
And another issue. 5e82b63f6 reduced the fft size from length to length-1. The resulting code is: out = fftw_malloc(sizeof(fftw_complex) * (unsigned int) fpts); ... plan_forward = fftw_plan_dft_r2c_1d(length-1, in, out, FFTW_ESTIMATE); ... fdvec[i][fpts-1].cx_real = out[fpts-1][0]/scale/2.0; fdvec[i][fpts-1].cx_imag = 0.0; This means ngspice returns a "junk" fft value at the last frequency bin. Because the code allocates and uses N/2+1 bins, but FFTW now only fills in (N-1)/2+1 bins. I verified this...
-
Quite slow, we are talking about 1.2V in 500us. I am pretty sure that it is the dc sweep the main problem, the tran results are reasonable.
-
Without having an opportunity to look at what you're doing... what is the speed of your input in transient? If it's anything other than very slow indeed, you won't get a good idea of the threshold voltages. -- Kind regards, Justin Fisher.
-
Hello, I am trying to characterize the switching threshold of two different hysteretic inverters. When I use transient analysis, I obtain reasonable results. However, when I perform a DC sweep, the extracted threshold depends strongly on the step size. For example: dc V1 0 1.2 1m and dc V1 0 1.2 10m produce different results. I expect some variation due to the different step sizes, but I would assume the threshold to be different of a max of ±10 mV. Instead, I observe discrepancies of several hundred...
-
Very well. Please stop ignoring errors when they are reported and instead engage in fact-based technical discussion. It's worth mentioning that by that comment I had been blocked from commenting, I only wanted to let him know there were problems. If you are the one who unblocked me, thank you. The commits have the following issues: The nyquist bin exists only when the number of FFT points is even. But commit d2b1ecbb2 applies the changed normalization fix to the last bin regardless of even/odd number...
