I have had numerous problems, just like other members: extremey frequent crashes, insane handling of directories, automatic updates wiping out everything (I havent made one for a year), plus minor other problems, like switching beween the different simulations, handling of the character size, etc. etc.
I often revert to IV, when I lose patience and want something working immediately
I often revert to IV, when I lose patience and want something working immediately
You can imagine I know this ;-)
- Acknowledge it is boring to calculate the period of a frequency.
- All my measuring parameters depend of {freq} I have to change the two in order to can swap from sin to square, and 4 parameters in the pulse.
It would not be a big deal to add a square and triangle generator to this app.
Yes we can do-it, I can drive my car without a cruise control too.
This said, I never had the curiositiy to compare Middlebrook and Tian on a CFA:.
Attachments
Last edited:
I never experienced a crash in two years now that I use LTspice (I used a paid-for sim before, but LTspice is MUCH better than what I had before).
I do have my own directories setup for my own models, libraries, symbols etc and the search paths set in LTspice. They stay intact through all updates.
When there's something I don't know (which happened a lot at the beginning, less now) I ask the friends at the Yahoo LTspice User Group and they quickly straighten me out. Works quite well.
Jan
I haven't used the Tian probe yet. It is a very nice tool for measuring open loop transfer in actual build systems. In LTspice I just plot Vo/(Vnoninv-Vinv) and be done ;-)
Here's the LT1028. A great tool also to see if the model follows the data sheet reasonably well.
Jan
Here's the LT1028. A great tool also to see if the model follows the data sheet reasonably well.
Jan
Attachments
Last edited:
Well, I do agree with the Professor that a really good structured software can be run with no reference to the manual, after the initial learning curve.
Once you understand the way it is set up, you can often guess the right approach and that is then often correct.
It's the badly structured and designed programs where you need to have the manual next to you.
I started to learn LTspice 2 years ago and bought the book by Brocard but rarely used it again after the first few weeks or so. LTspice is well structured, very consistent and logical.
Jan
Once you understand the way it is set up, you can often guess the right approach and that is then often correct.
It's the badly structured and designed programs where you need to have the manual next to you.
I started to learn LTspice 2 years ago and bought the book by Brocard but rarely used it again after the first few weeks or so. LTspice is well structured, very consistent and logical.
Jan
Last edited:
I use a lot of programs without having read any help or handbook. That makes the difference between Lightroom and Fireworks VS Photoshop for photography as an example.
This has a word: ergonomy. And a 'commercial' argue: User friendly.
When the development of a one click feature takes twice the time of an action that takes 10 and you have to repeat 10 times a day (or more), I use to be crossed against the devs.
I often noticed that some people like to play with primitive programs, a little like video games. Not my point. For me, it is a tool.
A tool has to be adapted to the work to be done and the human that use-it, not the contrary.
LTSpice is able to do incredible things. Save hours and hours of calculations (As an old man, I started my pro life in audio electronic with slide rule. ;-)
But when you are trying various compensations schemes in an amp in progress, by example, swapping the sims between distortion measurements, stability margins and square waves is something that i should make 10 times more rapid and easy if it was an open source program.
I tend to agree with each comment of Elvee about LTSpice.
Jan, it happened I was sometimes hired as a consultant for the features and ergonomy of complex gears. And I was involved in the development of various softwares as well. C, Pascal (Delphi) , Php, Javascript etc.
So, I'm very sensible to this point.
You immediately feel the difference, opening a software or a soft based gear if the devs were oriented in the *usage* or just giving access to the functions, self oriented ;-).
I have a Sony A7 camera. A technically very good camera that have near all the functions I need. The problem is they are so badly implemented that, in my own use (Manual focus, mechanical old lenses, Candid photography), it is impossible to have the instant access in manual focus help I need to be both fast and accurate enough.
All the features exists, so it should be so easy to Sony to improve the usage in less than a one man day work. And we had send them possible simple solutions. Sony refuse to take any suggestions into account, even when it is a petition signed by thousands of customers: Japanese pride ;-) My next camera will not be a Sony. More than this: no more any Sony product in my home.
Yes that happens. I've done a fair share of software development, mostly real-time stuff.
Reactions to my proposals have varied from 'just what I want' to 'that's stupid', for the same thing.
A friend of mine is a web developer for companies. Has the same experience, some love him, some will look for another guy as soon as they can.
No way you can please all of the people!
Jan
Reactions to my proposals have varied from 'just what I want' to 'that's stupid', for the same thing.
A friend of mine is a web developer for companies. Has the same experience, some love him, some will look for another guy as soon as they can.
No way you can please all of the people!
Jan
Before starting with LTspice I used Labcenter's VSM simulator, at least 10 years. Actually paid a yearly maintenance fee for it. Their philosophy was completely different than most sims.
They invented 'graph based simulation'. When you wanted say a transient run, you drew a transient graph, dragged the nodes you wanted to see onto the graph then hit spacebar. The sim would run and draw the curve on the graph.
It had one great thing: you could have several graphs on the screen at the same time, a transient graph, a spectrum, an ac analysis, so you saw all that info at the same time. After a change you could re-sim a single graph or all of them. I really liked it but got fed up with the yearly payments and decided to try LTspice, which understandably caused me much frustration until I grokked the concept behind it. Never looked back, but still miss that overview of several different sims at the same page.
Jan
They invented 'graph based simulation'. When you wanted say a transient run, you drew a transient graph, dragged the nodes you wanted to see onto the graph then hit spacebar. The sim would run and draw the curve on the graph.
It had one great thing: you could have several graphs on the screen at the same time, a transient graph, a spectrum, an ac analysis, so you saw all that info at the same time. After a change you could re-sim a single graph or all of them. I really liked it but got fed up with the yearly payments and decided to try LTspice, which understandably caused me much frustration until I grokked the concept behind it. Never looked back, but still miss that overview of several different sims at the same page.
Jan
Could be linked with the compatibility with Win 7, the fact that I opted for a non-default installation (not on the C drive), and bad luck, but normally all of that is a matter of IT good practices: when a software is supposed to be compatible with an OS it should be so, when it allows an installation elsewhere than in the default location, it should take care of the relocation issues, etc.
Instead, it scattered the various soft components everywhere in my computer and when I attempted to manually gather the pieces, it solved some issues but caused others.
In the end, when I managed to get something vaguely stable and working, I stopped any further attempts, fearing unintended consequences.
Add to that the various other quirks, like the need to manually switch between the simulation types, the font size on some components defaulting to the smallest, even after editing and saving, the crashes every third time I launch a sim....
By contrast, the IV version was completely problem-free and uneventful, and it still works perfectly now in a virtual machine.
I am not the only one experiencing problems: I solved (or rather handled) the directory issues thanks to the help of the net community, and the frequent crashes are also a frequent complaint.
It reminds me of the bad ol' Microsoft days
We are in the same boat here
. Or, to say better :-( (smiley here)I have found my issue. A servo acts in very low frequencies. Need time to stabilize.
We want to make measurements at high frequencies. If we compute with a start time long enough to allow the servo to reach its point of stabilisation, and number of point to can evaluate the high frequencies, it takes hours.
So, my solution to replace the servo out by a voltage was the trick. But I had to kill the servo itself, because it was at 1000 Hz in a unstable point.
I don't know the way to tell SPSpice to evaluate the servo + the amp in a fast way to find the DC operating point before to begin the detailed amp analysis.
Last, I don't believe one second in the distortions measurements I got: 0.000056% at 1KHz, 0.000030% at 100Hz, 0.000638% at 10KHz. I know i'm talented*, but not at this point ;-)
It is a simple CFA, Diamond input with current sources, Cascode VAF, driver and a pair of HEXFETs (2sk134 & co) out devices, +-60V out. Cordel models.
*For those with a second degree alergia, it is a joke.
Last edited:
As a man in his late forties, I remember how we used to run PStar simulations at university. There was no schematic entry program, so you drew your schematic on a piece of paper, numbered the nodes and typed in a netlist in an ASCII file with extension .pstar. After adding the simulation directives you could run it from the command line: pstar <filename>.pstar.
In the beginning there also was no graphic postprocessing tool, so all graphs were just made out of stars and similar symbols in the ASCII output file of PStar. The x-axis was vertical, so it could be as long as needed, but the y-axis had a resolution of less than 80 points, limited by the number of characters that fit on a line. Later we got the cgap graphic postprocessor, which was really a big improvement.
Sometimes I used the wrong extension by mistake and ran PStar on its own output file. It would then first write a header, then read in the header, parse it, find that it was not PStar syntax and write an error message. Then it would read in its own error message, parse it, and generate another error message because the error message was not in PStar syntax. Within a few minutes you would have many megabytes of nested error messages.
I have found my issue. A servo acts in very low frequencies. Need time to stabilize.
We want to make measurements at high frequencies. If we compute with a start time long enough to allow the servo to reach its point of stabilisation, and number of point to can evaluate the high frequencies, it takes hours.
So, my solution to replace the servo out by a voltage was the trick. But I had to kill the servo itself, because it was at 1000 Hz in a unstable point.
I don't know the way to tell SPSpice to evaluate the servo + the amp in a fast way to find the DC operating point before to begin the detailed amp analysis.
Last, I don't believe one second in the distortions measurements I got: 0.000056% at 1KHz, 0.000030% at 100Hz, 0.000638% at 10KHz. I know i'm talented*, but not at this point ;-)
It is a simple CFA, Diamond input with current sources, Cascode VAF, driver and a pair of HEXFETs (2sk134 & co) out devices, +-60V out. Cordel models.
*For those with a second degree alergia, it is a joke.
So it's a settling issue after all. The bias point is by default calculated before the start of the transient run, but the start of the signal disturbs it.
When your circuit behaves similar to an integrator, it may help to have a jump from the average value to the peak value at t = 0, rather than a sine wave that starts from the zero crossing. Draw a signal that is zero for t < 0 and sin(omega t) for t >= 0 and its time integral and you will see the problem. Draw a signal that is zero for t < p and cos(omega t) for t >= 0 and its time integral and you will see why it may help.
By the way, a Hann window makes the FFT far less sensitive to incomplete settling issues. Or more accurately, with a Hann window it is mainly the bins adjacent to those with the signal that are affected.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.