I have mine model in the C:\Program Files\LTC\LTspiceXVII\lib\cmp\standard.mos. copy that file into ltspice directory where yours is. put a standard mosfet on your schematic rightclick it and choose the dn2540.
But these are not all gold what blinks. As for all mosfets. http://www.bartola.co.uk/valves/2015/08/31/ccs-not-everything-that-glitters-is-gold-part-i/
But these are not all gold what blinks. As for all mosfets. http://www.bartola.co.uk/valves/2015/08/31/ccs-not-everything-that-glitters-is-gold-part-i/
Interesting article. Is there a part ii?
I'm just using the DN2540 until I can find a good model for an IXYS 10M45S.
Hi Everyone,
I'd like to update my previous post. Some of that stuff was a bit incorrect. Hopefully this isn't.
Keep in mind that I'm still only talking about LTspiceXVII running on Linux under Wine.
OK,
Suppose you add a folder containing your new part symbols under "/home/username/LTspiceXVII/lib/sym".
It may look like "/home/username/LTspiceXVII/lib/sym/3rd Party Symbols 30 May 2018" or something similar.
You will see your new folder and .sym files show up in the "Select Component Symbol" window the next time the LTspiceXVII program is run.
It will even survive and Update (called "Sync Release" from the "Tools" menu) intact.
However, if you were to rename or delete "/home/username/LTspiceXVII", it would take a bit longer for the program to start next time AND all your
new subfolders and symbol files (and all your new .mod, .sub, .lib files) would be gone!
For Linux users under Wine it looks like either LTspiceXVII or Wine is checking for the presence of "/home/username/LTspiceXVII" on the program launch.
If it can't find it, then a copy of "/home/username/.wine/drive_c/Program Files/LTC/LTspiceXVII" is made in "/home/username".
This becomes the new "/home/username/LTspiceXVII". This copy includes the two subfolders called "/examples" and "/lib" but excludes the eleven files contained
in ".../LTspiceXVII" ( 2 .dll, 3 .txt, 3 .exe, 1 .chm, 1 .bin, and 1 .info files).
Now if you added a folder containing your new part symbols under the .wine path of "/home/username/.wine/drive_c/Program Files/LTC/LTspiceXVII", it would only be copied over
to the new "/home/username/LTspiceXVII" folder after you did a "Sync Release" from the Tools Menu.
I just discovered this little fact the other day but the ramifications as to how LTspiceXVII operates are huge.
The Bottom Line Is:
1) If you modify "/home/username/LTspiceXVII" directly then your changes will show up in the "Select Component Symbol" window the next time the LTspiceXVII program is run.
2) If you modify the .wine path of "/home/username/.wine/drive_c/Program Files/LTC/LTspiceXVII", then your changes will only show up after you do a "Tools - Sync Release" (and maybe re-run the program).
Here is were I'd like to take back my previous rant about never touching the "/home/username/LTspiceXVII" folder directly.
The are advantages and disadvantages to both methods.
For method 1 the big advantage is you can have access to your new part files without having to use the internet. Just copy your files from say a USB stick and re-run the program.
The "Tools - Sync Release" needs an internet connection to complete.
For method 2 the advantage is your files and folders are a little more protected down the hidden .wine path. Also, should the "/home/username/LTspiceXVII" folder ever
get deleted, renamed, or corrupted then a quick "Tools - Sync Release" and you're back in buisness with your customized file structure again.
What does everyone think?
(Try not to flame me to bad; this is only my third post.)
Cartman222
I'd like to update my previous post. Some of that stuff was a bit incorrect. Hopefully this isn't.
Keep in mind that I'm still only talking about LTspiceXVII running on Linux under Wine.
OK,
Suppose you add a folder containing your new part symbols under "/home/username/LTspiceXVII/lib/sym".
It may look like "/home/username/LTspiceXVII/lib/sym/3rd Party Symbols 30 May 2018" or something similar.
You will see your new folder and .sym files show up in the "Select Component Symbol" window the next time the LTspiceXVII program is run.
It will even survive and Update (called "Sync Release" from the "Tools" menu) intact.
However, if you were to rename or delete "/home/username/LTspiceXVII", it would take a bit longer for the program to start next time AND all your
new subfolders and symbol files (and all your new .mod, .sub, .lib files) would be gone!
For Linux users under Wine it looks like either LTspiceXVII or Wine is checking for the presence of "/home/username/LTspiceXVII" on the program launch.
If it can't find it, then a copy of "/home/username/.wine/drive_c/Program Files/LTC/LTspiceXVII" is made in "/home/username".
This becomes the new "/home/username/LTspiceXVII". This copy includes the two subfolders called "/examples" and "/lib" but excludes the eleven files contained
in ".../LTspiceXVII" ( 2 .dll, 3 .txt, 3 .exe, 1 .chm, 1 .bin, and 1 .info files).
Now if you added a folder containing your new part symbols under the .wine path of "/home/username/.wine/drive_c/Program Files/LTC/LTspiceXVII", it would only be copied over
to the new "/home/username/LTspiceXVII" folder after you did a "Sync Release" from the Tools Menu.
I just discovered this little fact the other day but the ramifications as to how LTspiceXVII operates are huge.
The Bottom Line Is:
1) If you modify "/home/username/LTspiceXVII" directly then your changes will show up in the "Select Component Symbol" window the next time the LTspiceXVII program is run.
2) If you modify the .wine path of "/home/username/.wine/drive_c/Program Files/LTC/LTspiceXVII", then your changes will only show up after you do a "Tools - Sync Release" (and maybe re-run the program).
Here is were I'd like to take back my previous rant about never touching the "/home/username/LTspiceXVII" folder directly.
The are advantages and disadvantages to both methods.
For method 1 the big advantage is you can have access to your new part files without having to use the internet. Just copy your files from say a USB stick and re-run the program.
The "Tools - Sync Release" needs an internet connection to complete.
For method 2 the advantage is your files and folders are a little more protected down the hidden .wine path. Also, should the "/home/username/LTspiceXVII" folder ever
get deleted, renamed, or corrupted then a quick "Tools - Sync Release" and you're back in buisness with your customized file structure again.
What does everyone think?
(Try not to flame me to bad; this is only my third post.)
Cartman222
Then read first, the DN2540 has better HF, and it is in fact the same depletion mosfet. Model of 10M45S is also in link.
Tube DIY Asylum
Better is lower mosfet in ccs be a small one, because there is not much voltage over it, the top mosfet has voltage over it and do the most work. a Jfet is be used normally.
regards
I have it working now. The model was good I just wasn't using it correctly.
According to CCS performance measurements the IXYS 10M45S is better than a single DN2540 but not as good as a DN2540 Cascode at least up to 10kHz. I plan to do more testing based on the link you provided. I just need to get the standard tubelab Universal Driver Board model working first.
According to CCS performance measurements the IXYS 10M45S is better than a single DN2540 but not as good as a DN2540 Cascode at least up to 10kHz. I plan to do more testing based on the link you provided. I just need to get the standard tubelab Universal Driver Board model working first.
After you have displayed the ripple current, you can ctrl-click on the trace name and LTSpice will tell you the RMS level of the ripple current, which is what you want if you are trying not to blow up lytics.
The measurement is taken over the area shown in the waveform viewer, so you need to zoom in to exclude for example inrush current or other short-time events which do not count towards ripple current.
thanks for the reminder.
Coming back to FFT if I may, Karl you did a great job explaining stuff here: Installing and using LTspice IV (now including LTXVII). From beginner to advanced.
But you have used 4kHz which of course fits nicely within a 5ms window. What about the case when the signal period is not an integer part of the measurement window? Does it still work as you explained or do I pad the time window to make it integer or use an FFT window?
Like when I have 1010Hz and a 5ms measurement interval?
Jan
But you have used 4kHz which of course fits nicely within a 5ms window. What about the case when the signal period is not an integer part of the measurement window? Does it still work as you explained or do I pad the time window to make it integer or use an FFT window?
Like when I have 1010Hz and a 5ms measurement interval?
Jan
That's a good question Jan.
I quickly tried this on the JLH69 amp running a 1kHz input and 5ms sim time. The timestep is 0.019073uS
That gives us the first FFT. Distortion is 0.042%
Now change the input to 1010Hz and yes, we have to alter the sim run time to fit. To keep at showing 5 cycles on the screen means we have to run the sim for 0.00495 seconds or 4.95ms.
The time step is now 4.950495ms divided by 262144 which is 1.888463E-8 which is 0.019uS.
The second FFT shows this. Distortion is essentially the same as well within rounding limits of entering the timesteps manually.
So yes, it all seems to work as it should but you have to do a bit of mental juggling to do it this way. Setting the sim run time to exactly fit a known number of cycles seems to be the key. Keeping the run time at 5ms produces massive errors for the FFT of the 1010Hz run.
Last two images are of doing just that. The FFT is non sensical, the distortion seems pretty much unaffected.
I quickly tried this on the JLH69 amp running a 1kHz input and 5ms sim time. The timestep is 0.019073uS
That gives us the first FFT. Distortion is 0.042%
Now change the input to 1010Hz and yes, we have to alter the sim run time to fit. To keep at showing 5 cycles on the screen means we have to run the sim for 0.00495 seconds or 4.95ms.
The time step is now 4.950495ms divided by 262144 which is 1.888463E-8 which is 0.019uS.
The second FFT shows this. Distortion is essentially the same as well within rounding limits of entering the timesteps manually.
So yes, it all seems to work as it should but you have to do a bit of mental juggling to do it this way. Setting the sim run time to exactly fit a known number of cycles seems to be the key. Keeping the run time at 5ms produces massive errors for the FFT of the 1010Hz run.
Last two images are of doing just that. The FFT is non sensical, the distortion seems pretty much unaffected.
Attachments
Anthony, I tried to set up this string of .param expressions but hit a wall. Apparently I cannot uses expressions within a .param statement, see attached. I get an error on the '-' in the expression.
(There's other errors but its more a test of the concept).
Would you share your method?
Jan
Attachments
Got it to work thanks to Ian Hegglun:
He send me this:
.options plotwinsize=0 numdgt=7 method=gear numdgt=15 ptrantau=0
.param FFT=2**16 dlycyc=1 numcyc=5 ;<-change
.param simtime=numcyc/Freq+dlytime
.param dlytime=dlycyc/Freq ;needs somewhere .param Freq= 50
.param timestep=(simtime-dlytime)/FFT
; .option reltol=1e-6 ;only if lower floor needed
.four {Freq} V(Vout) V(Vin)
.tran 0 {simtime} {dlytime} {timestep} ;For High Precision FFT
;Simulate>Control>SPICE>Solver=Alternate Alt.Solver gives 60dB lower floor (-260dB)
Works like a charm, Vin is now -250dB. Always a good test - if Vin shows distortion, you're not doing it right!
More here:
https://www.stromrichter.org/attachment.php?aid=724
or
Slewmaster - CFA vs. VFA "Rumble"
BTW Ian said he found it on diyaudio, see the links. So that squares the circle ;-)
Jan
He send me this:
.options plotwinsize=0 numdgt=7 method=gear numdgt=15 ptrantau=0
.param FFT=2**16 dlycyc=1 numcyc=5 ;<-change
.param simtime=numcyc/Freq+dlytime
.param dlytime=dlycyc/Freq ;needs somewhere .param Freq= 50
.param timestep=(simtime-dlytime)/FFT
; .option reltol=1e-6 ;only if lower floor needed
.four {Freq} V(Vout) V(Vin)
.tran 0 {simtime} {dlytime} {timestep} ;For High Precision FFT
;Simulate>Control>SPICE>Solver=Alternate Alt.Solver gives 60dB lower floor (-260dB)
Works like a charm, Vin is now -250dB. Always a good test - if Vin shows distortion, you're not doing it right!
More here:
https://www.stromrichter.org/attachment.php?aid=724
or
Slewmaster - CFA vs. VFA "Rumble"
BTW Ian said he found it on diyaudio, see the links. So that squares the circle ;-)
Jan
There is (to me) one obvious reason for a integer amount of (whole) sines to be evaluated for FFT, any thing other than a complete sine must be distortion 
Something like:
.5 sine is 50% distortion
1 sine is 0% distortion
1.5 sine is [probably] 25% distortion (e.g. 25% of 2 sines is missing)
2 sine is 0% distortion
2.5 sine is [probably] 16.66666..% distortion (e.g. 1/6 of 3 sines is missing)
…
I think that Cordell advices 10 compleet sins for an FFT measurement.
Something like:
.5 sine is 50% distortion
1 sine is 0% distortion
1.5 sine is [probably] 25% distortion (e.g. 25% of 2 sines is missing)
2 sine is 0% distortion
2.5 sine is [probably] 16.66666..% distortion (e.g. 1/6 of 3 sines is missing)
…
I think that Cordell advices 10 compleet sins for an FFT measurement.
I think the reason is that the FFT assume an infinitely long signal. If you take a finite part it will work as long as the end point of the sine where you stop is exactly the same as the begin point, so that an integer # of cycles is transformed. So that you could, if you wish, seamlessly connect the end back to the beginning.
Note that the start- and end-point need not be at zero, just that they are the same.
If you try to transform a non-integer # of cycles you must use an FFT window; what the window does is decrease the signal amplitude toward the end- and begin-point to zero so that the FFT *thinks* they are the same.
The various windows differ in how aggressively they decrease the level towards the begin- and end-points.
Jan
Note that the start- and end-point need not be at zero, just that they are the same.
If you try to transform a non-integer # of cycles you must use an FFT window; what the window does is decrease the signal amplitude toward the end- and begin-point to zero so that the FFT *thinks* they are the same.
The various windows differ in how aggressively they decrease the level towards the begin- and end-points.
Jan
Just to make things clear (for me), we (Jan and I) are basically saying the same, you need an integer number of waves or a function to make (the number of sines you are using [non integer or other]) look like (some sort of) integer (e.g. using a windowing function).
Also note, selecting the windowing function is also affecting other result-parameters/-presentation parts of the FFT, like noise and aliasing representation, most of the time I will use 'flat-top'.
Also note, selecting the windowing function is also affecting other result-parameters/-presentation parts of the FFT, like noise and aliasing representation, most of the time I will use 'flat-top'.
You do not need the 'curlies' in a .param statement.
You do need the 'curlies' when substituting a [.param] value in most commands/directives.
P.s. evalper has an error, it is the 'extra' 'm' that follows the expression.
P.s. the macro[param etc] evaluation-engine is of the type 'merge-first-then-evaluate' when an error happens the evaluator will report the statement in which it occurred, not where it originated (this can be puzzling at times
)P.p.s.
Like in:
.param a = error
.param b = 6
.param c = a + b
May (but not surely) report an error in the '.param c...' statement and may never report an error in the '.param a...' statement, this gets real complicated [to solve] when many statements are 'mixed' spread over a large solution, it would be nice if the evaluator was a bit 'modernized'.
Last edited:
Yes we are at the same sheet. Of course the problem with windowing is that it gives spurious components in the spectrum and lowers resolution. The nice thing with LTspice is that you can precisely specify the various parameters and not need a window.
With the numbers I posted before I get about -250dB on the voltage source. So anything above that is from the circuit. That's a low enough measurement floor for most of my amps ;-)
Jan
With the numbers I posted before I get about -250dB on the voltage source. So anything above that is from the circuit. That's a low enough measurement floor for most of my amps ;-)
Jan